первый

второй

Есть удобный сервис для планов :) https://explain.depesz.com/

Ну тут у вас 2500мс против 2100. И видимо как раз из-за буфуров (см. buffers read в первом плане и его отсутствие во втором).

Есть удобный сервис для планов :) https://explain.depesz.com/

+1

В ситуации когда запрос выполняется десятки секунд у вас скорее всего все читается с диска (не будет buffers shared hit).

Ну тут у вас 2500мс против 2100. И видимо как раз из-за буфуров (см. buffers read в первом плане и его отсутствие во втором).

а как его найти

кажется вижу, где разница

а как это пофиксить можно?

ну если я спрашиваю, то скорее всего, мое решение чем то обосновано?

Это на самом деле не так. Есть тысяча и одно объяснение что вам так делать не надо.

tail -f [файл лога]

А дальше?

И 3Gb для shared buffers многотовато при 8Gb RAM.

Как как?

а как это пофиксить можно?

Что именно? Это просто эффект кэширования данных. Тут либо кэшировать больше (добавить RAM) / читать быстрее (улучшить дисковую подсистему), либо читать меньше (оптимизировать запрос / создать подходящие индексы).

Понял, спасибо. Но если вот такой кейс. Юзер утром приходит запускает приложение и ждет инфу, которая нужна ему 1 раз в день. И первый запрос длится 70 сек, а второй уже 2-3. Мне тут уже советовали, поставить шедуллер, который рано утром будет для юзеров прогревать базу ?

делая запросы, на получение инфы.

Может как-то можно узнать, сколько времени будет длиться такой кеш? Когда, например, он сбрасывается и нужно снова читать с диска.

а как это пофиксить можно?

Можно- переписать запрос или больше памяти в сервак добавть для shared buffer . Могу сразу сказать что в пг shared buffer работает мин в 2 раза быстрее чем кэш ос. Поэтому советы про маленький shared buffer считаю вредными

Может как-то можно узнать, сколько времени будет длиться такой кеш? Когда, например, он сбрасывается и нужно снова читать с диска.

Vm.dirty_ratio и прочие товарищи

Это для ос

Check point completion target для pg

Больше ничего не придумали

Может как-то можно узнать, сколько времени будет длиться такой кеш? Когда, например, он сбрасывается и нужно снова читать с диска.

Сбрасывается постепенно на усмотрение пг

Может как-то можно узнать, сколько времени будет длиться такой кеш? Когда, например, он сбрасывается и нужно снова читать с диска.

Он "сбрасывается" (я про shared_buffers), когда его что-то вытесняет (т.е. запросам становятся нужнее другие данные).

Он "сбрасывается" (я про shared_buffers), когда его что-то вытесняет (т.е. запросам становятся нужнее другие данные).

Не нужнее, а просто нужно

Check point completion target для pg

Спасиб, сейчас буду гуглить все это. А то первый раз слышу, что это) кек

Не нужнее, а просто нужно

Нужнее. "Горячие" данные оттуда не очень-то вытеснишь. ;)

Check point completion target для pg

А причём тут это, кстати?

Он "сбрасывается" (я про shared_buffers), когда его что-то вытесняет (т.е. запросам становятся нужнее другие данные).

спасиб. Получается если shared_buffers много, то кешировать будет сколько влезет.

Понял, спасибо. Но если вот такой кейс. Юзер утром приходит запускает приложение и ждет инфу, которая нужна ему 1 раз в день. И первый запрос длится 70 сек, а второй уже 2-3. Мне тут уже советовали, поставить шедуллер, который рано утром будет для юзеров прогревать базу ?

Ну или прогревайте, в самом деле... ;) А остальные варианты я уже вроде назвал. Вот ещё: какая версия PostgreSQL?

10

10

Значит, upgrade Вам не поможет. ;)

тогда так. 1. попробую оптимизировать запрос. 2. добавлю RAM и на крайний буду прогревать, на большее денег и времени не дадут)

Может как-то можно узнать, сколько времени будет длиться такой кеш? Когда, например, он сбрасывается и нужно снова читать с диска.

Pg_buffercache посмотрите

Pg_buffercache посмотрите

читаю сейчас за это, но пока не понимаю как юзать

Да там понимать то нечего особо

Ну или прогревайте, в самом деле... ;) А остальные варианты я уже вроде назвал. Вот ещё: какая версия PostgreSQL?

Прогревать это для pgbench. В остальном это дурь

И вытеснится при первой возможности

читаю сейчас за это, но пока не понимаю как юзать

Это может не помочь, если надо узнать, надолго ли нужные данные будут оставаться в кэше, к сожалению. Т.к. это зависит от _нагрузки_ (других запросов) в интересующий Вас период времени.

Самое оптимально для пг это оптимальные запросы

Остальное это мертвому припарки и отсрачивание агонии

понял, спасиб

Это может не помочь, если надо узнать, надолго ли нужные данные будут оставаться в кэше, к сожалению. Т.к. это зависит от _нагрузки_ (других запросов) в интересующий Вас период времени.

Они будут оставаться в кэше ровно столько сколько неизвестно

И вытеснится при первой возможности

Ну, можно так, что и не при первой... но да, проблема в том, что не угадаешь, когда (и, возможно, очень быстро). :(

При второй. Это рояля не меняет. Или база влезает в кеш или нет, другого не дано. Если база есть определенного размера значит она нужна вся

Самое оптимально для пг это оптимальные запросы

Ну мы-то не для PostgreSQL работаем, я надеюсь? ;) Т.е. просто добавить памяти может быть тупо выгоднее...

Ну мы-то не для PostgreSQL работаем, я надеюсь? ;) Т.е. просто добавить памяти может быть тупо выгоднее...

До поры до времени

До поры до времени

И до этой поры может быть бесконечно далеко... разве что время DBA стоит копейки. ;)

Если запрос кривой то можно хоть септильон мегабайт выделить

И до этой поры может быть бесконечно далеко... разве что время DBA стоит копейки. ;)

Для пг время дба стоит много больше чем для других баз

Ибо нет инструментов для быстрого разрешения инцидентов кроме как мозг дба

Все остальное от лукавого

Ктобы что не говорил

Для пг время дба стоит много больше чем для других баз

Да, хорошо бы, но врядли так уж намного. ;)

Ибо нет инструментов для быстрого разрешения инцидентов кроме как мозг дба

Хмм... смотря каких инцидентов.

Намного стоят лицухи и намного же стоят простои

кажется на эстейт проперти надо сделать более селективный индекс

Хмм... смотря каких инцидентов.

Для инцидентов больше чем проставить shared buffers > 128mb

кажется на эстейт проперти надо сделать более селективный индекс

это как?

Для инцидентов больше чем проставить shared buffers > 128mb

Я бы сказал наоборот, и (вроде) не так уж редко. Т.е. добавление 256 Гб памяти легко может дать больший эффект, чем недели усилий DBA. ;)

это как?

у тебя по точкам нашлось 290к записей, потом пошел джойн к проперти с кучкой фильтров и наджойнилось всего 7к записей возможно тебе поможет индекс на условие которое много отбрасывает результатов

это как?

Подождите. Если Вы хотите (и можете) именно оптимизировать запрос, занимайтесь этим. А если Вы хотите, чтобы Вам в этом помогли, занимайтесь правильно, т.е. выкладывайте \d всех таблиц, сам запрос и EXPLAIN (ANALYZE, BUFFERS). ;)

у тебя по точкам нашлось 290к записей, потом пошел джойн к проперти с кучкой фильтров и наджойнилось всего 7к записей возможно тебе поможет индекс на условие которое много отбрасывает результатов

например на (эрия, последняя продажа)

у тебя по точкам нашлось 290к записей, потом пошел джойн к проперти с кучкой фильтров и наджойнилось всего 7к записей возможно тебе поможет индекс на условие которое много отбрасывает результатов

сейчас буду там смотреть, спасиб

Я бы сказал наоборот, и (вроде) не так уж редко. Т.е. добавление 256 Гб памяти легко может дать больший эффект, чем недели усилий DBA. ;)

Конечно. Это если размер базы <256 гб. Только вот по памяти такое редко у кого встречается. Ибо пг используют те у кого этих гб много меньше чем размер базы. И им надо sql знать идеально.

Я бы сказал наоборот, и (вроде) не так уж редко. Т.е. добавление 256 Гб памяти легко может дать больший эффект, чем недели усилий DBA. ;)

лучше ссд добавлять

ребята, есть что-то получше pg_basebackup, когда нужно забэкапить базу вплоть до индексов?

лучше ссд добавлять

Это до поры до времени. Все равно что рамы добавить

ребята, есть что-то получше pg_basebackup, когда нужно забэкапить базу вплоть до индексов?

не встречал

ребята, есть что-то получше pg_basebackup, когда нужно забэкапить базу вплоть до индексов?

Pg_probackup

спасибо, посмотрю)

Лучше только cp если в один поток

Приходите на конфу, мы там расскажем

Что почем

Конечно. Это если размер базы <256 гб. Только вот по памяти такое редко у кого встречается. Ибо пг используют те у кого этих гб много меньше чем размер базы. И им надо sql знать идеально.

Не обязательно "размер базы <256 гб". Размер бвзы может быть любой, лишь бы часто используемые данные в память +-влезали. > Ибо пг используют те у кого этих гб много меньше чем размер базы. Откуда статистика? Вообще, к сожалению, базы данных, даже opensource —- это не для нищих. :(

а если сравнивать скорость между pg_probackup и pg_basebackup — есть ли великая разница?

Не обязательно "размер базы <256 гб". Размер бвзы может быть любой, лишь бы часто используемые данные в память +-влезали. > Ибо пг используют те у кого этих гб много меньше чем размер базы. Откуда статистика? Вообще, к сожалению, базы данных, даже opensource —- это не для нищих. :(

Последний коммент огонь!

а если сравнивать скорость между pg_probackup и pg_basebackup — есть ли великая разница?

Дело не только в скорости, но и в валидации того что забекапилм

Basebackep это почти cp

Без проверок

ок, спасибо)

а если сравнивать скорость между pg_probackup и pg_basebackup — есть ли великая разница?

По крайней мере в раза полтора-два.

в чью сторону-то

в чью сторону-то

Ессно бейсбэкап быстрее Хотя пробэкап не пробовал

сейчас буду там смотреть, спасиб

ну чо?

ну чо?

не могу понять как и где

там юзается поиск в радиусе 100км например

и сортируется по растоянию

самые ближайшие

create index concurrently on estate_properties(building_area,latest_sale_recording_date);

Оо, спс. Сейчас попробую

Вы бы вставляли в виде текста (всё, о чём Вас просили) на какой-нибудь paste site, а сюда ссылку.