Size: a a a

pgsql – PostgreSQL

2021 January 21

ПЕ

Петр Егоров... in pgsql – PostgreSQL
на графике чем больше шаред, тем меньше тпс
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Петр Егоров
судя по графику разве не наоборот?
(посмотрел по диагонали)
правая часть (75%) даёт больше TPS чем левая (25%)
источник

ПЕ

Петр Егоров... in pgsql – PostgreSQL
хотя, когда вся в бд в шаред, то тпс больше вроде
источник

J

John Roe in pgsql – PostgreSQL
См. личные сообщения
источник

ПЕ

Петр Егоров... in pgsql – PostgreSQL
при маленьком шаред и большом файловом кеше тпс больше, чем при 25% шаред (как часто все рекомендуют) и 75 кэш
источник

ПЕ

Петр Егоров... in pgsql – PostgreSQL
вот это интересно
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Петр Егоров
при маленьком шаред и большом файловом кеше тпс больше, чем при 25% шаред (как часто все рекомендуют) и 75 кэш
на основании чего такой вывод? в правой части график практически горизонтальный
источник

ПЕ

Петр Егоров... in pgsql – PostgreSQL
где больше тпс? при шаред 128 МБ (0%) или при 8 ГБ (25%)?
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Петр Егоров
где больше тпс? при шаред 128 МБ (0%) или при 8 ГБ (25%)?
а… ну да. но следует учесть, что это синтетика — тут надо делать тесты под вашу нагрузку.
+ сам тест был на этой же машине, тоже могло повлиять
источник

ПЕ

Петр Егоров... in pgsql – PostgreSQL
ессно, все параметры настраиваются индивидуально на каждом инстансе
просто обратил внимание, потому что везде в рекомендациях 25%
источник

V

Viktor in pgsql – PostgreSQL
Часто ли используются PL/pgSQL блоки отдельно?
источник

am

a m in pgsql – PostgreSQL
Да, так и должно быть.
Но я все жду случая, когда ковыряние этих буферов — вместе с нудной перезагрузкой, разогревом кеша, прогонкой тестов и фиксацией изменений в производительности на графиках — окупит человеко-часы настраивальщика с учетом стоимости плашек с жаренным песком из ближайшего магазина «эльдорадо».
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Alexey Stavrov
Всем привет.
Представим, что есть запрос вида:
update x set y=1;
Добавим к этому запросу бесполезный join с таблицей, увеличивая сложность этого запроса на размер данной таблицы:
update x set y = 1 from z;

Получается , что одна и та же запись обновляется |z| раз. В pg не бывает с этим проблем, что в одном и том же стейтменте запись обновляется многократно? Если бывают, то есть ли пример этого?
А Вы пробовали просто воспроизвести (кстати, зачем)?
Вообще, в документации пишут следующее:

Trying to update the same row twice in a single statement is not supported. Only one of the modifications takes place, but it is not easy (and sometimes not possible) to reliably predict which one. This also applies to deleting a row that was already updated in the same statement: only the update is performed. Therefore you should generally avoid trying to modify a single row twice in a single statement.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Igor Chizhov
Ещё раз поясню, что не я выбирал и не покупал этот сервис. Работаю с тем, что предоставил заказчик. Предполагаю, что кто-то из 5 с половиной тысяч здесь присутствующих работал с сервисом Я.Облака.
Да и потом, я задал конкретный вопрос: стоит ли увеличивать shared_buffers с 8 Гб при наличии 48 Гб оперативы? Общий размер таблиц с индексами порядка 36 Гб.
К счастью, параметры PostgeSQL можно менять через консоль.
Попробовать и сравнить-то можно. Но для этого мониторинг должен быть, само собой.
И измениться всё может сильно, в принципе (т.е. оптимальная настройка может отличаться от default раза в три, например).
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
a m
Да, так и должно быть.
Но я все жду случая, когда ковыряние этих буферов — вместе с нудной перезагрузкой, разогревом кеша, прогонкой тестов и фиксацией изменений в производительности на графиках — окупит человеко-часы настраивальщика с учетом стоимости плашек с жаренным песком из ближайшего магазина «эльдорадо».
Benchmarking вообще штука сложная. Но откуда тут лишние человеко-часы?
На практике первичная вполне приемлемая настройка под "железо" / нагрузку занимает от силы час (и её можно выполнять как часть базовой настройки OS и PostgreSQL), нередко с существенным эффектом, так что обычно оно того стоит, нет?
источник

AI

Anton Igin in pgsql – PostgreSQL
Всем привет, нужен совет

оптимизирую запрос, в нем следующий отрывок:
Seq Scan on core_course  (cost=0.00..39.59 rows=70 width=908)
                         Filter: ((NOT is_removed) AND (published_at IS NOT NULL) AND (started_at >= '2021-01-21 19:44:02.212586'::timestamp without time zone))

Создаю индекс:
CREATE INDEX public_qs_index ON public.core_course USING btree (started_at, published_at, is_removed)

Но индекс не задействуется. Почему? Неправильно создал?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Anton Igin
Всем привет, нужен совет

оптимизирую запрос, в нем следующий отрывок:
Seq Scan on core_course  (cost=0.00..39.59 rows=70 width=908)
                         Filter: ((NOT is_removed) AND (published_at IS NOT NULL) AND (started_at >= '2021-01-21 19:44:02.212586'::timestamp without time zone))

Создаю индекс:
CREATE INDEX public_qs_index ON public.core_course USING btree (started_at, published_at, is_removed)

Но индекс не задействуется. Почему? Неправильно создал?
Потому что оно того не стоит, скорее всего, и PostgreSQL это правильно оценивает.
А вообще, лучше дать больше информации — в идеале всё то, что обычно требуется для того, чтобы подсказать по оптимизации запросов.
источник

am

a m in pgsql – PostgreSQL
Yaroslav Schekin
Benchmarking вообще штука сложная. Но откуда тут лишние человеко-часы?
На практике первичная вполне приемлемая настройка под "железо" / нагрузку занимает от силы час (и её можно выполнять как часть базовой настройки OS и PostgreSQL), нередко с существенным эффектом, так что обычно оно того стоит, нет?
То, что вы описали — это называется «воображаемая оптимизация». Это примерно как компьютерные мастера, что смотрят на нас добрыми лицами с объявлений на дверях подъездов, своим клиентам диски дефрагментируют.
источник

am

a m in pgsql – PostgreSQL
Anton Igin
Всем привет, нужен совет

оптимизирую запрос, в нем следующий отрывок:
Seq Scan on core_course  (cost=0.00..39.59 rows=70 width=908)
                         Filter: ((NOT is_removed) AND (published_at IS NOT NULL) AND (started_at >= '2021-01-21 19:44:02.212586'::timestamp without time zone))

Создаю индекс:
CREATE INDEX public_qs_index ON public.core_course USING btree (started_at, published_at, is_removed)

Но индекс не задействуется. Почему? Неправильно создал?
Строчек мало. Строчек в табличку добавьте.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
a m
То, что вы описали — это называется «воображаемая оптимизация». Это примерно как компьютерные мастера, что смотрят на нас добрыми лицами с объявлений на дверях подъездов, своим клиентам диски дефрагментируют.
А наблюдаемая разница в показателях средств мониторинга, отличия в результатах правильно проведённых benchmarks — тоже воображаемые? ;)
Т.е. аналогия тут некорректна.
источник