https://postgrespro.ru/docs/postgresql/9.6/runtime-config-autovacuum.html тут не нашел .

Парни напомните плиз нужно ли рестартовать базу после того как на таблицу навесил индивидуальные параметры автовакума ?

не нужно, но новые настройки например костов применятся только к новым процессам автовакуума

Спасибо .

можно например убить уже запущенные если хочется форсануть

не, норм я подожду там не долго

Коллеги непонятная ситуация : похоже что статистика при автовакуме не передается слэйву. хотя после ручного запуска vacuum analyze все доходит . суть такая есть часто изменяющаяся таблица при запросе на реплике попадаю на большой Heap Fetches: 18623 запрос делается до 400 мсек как только на мастере запускаю анализ Heap Fetches: 6394 запрос исполняется 5-10 мсек прикрутил к таблице alter table callback SET (autovacuum_analyze_scale_factor = 0.0); alter table callback SET (autovacuum_analyze_threshold = 500 ); Вижу в статистике автовакуум по ней ходит но толку мало на картинке это выглядит так : (резкие спады это ручной запуск анализа на мастере )

что я могу упустить в автовакуме ?

у тебя не append only случайно?

да только добавляются записи

и скан у тебя index only должен был быть?

Index Only Scan using idx_callback__status_next_run_at_2 on callback t

так и есть

напиши, пожалуйста, в этот тред, что и тебя эта проблема покусала: http://www.postgresql-archive.org/All-Taxi-Services-need-Index-Clustered-Heap-Append-td6008728.html

изветсный баг ? !

формально - документированное поведение

мда , но немного нелогичное

ты прочитал тред? :)

нет еще , там чето много :) и по буржуйскому , я медленно читаю

* EXPLAIN (BUFFERS) revealed that Visibility Map is never being frozen, as autovacuum ignores append-only never-updated never-deleted table that is only truncated once a day. No way to force autovacuum on such table exists.

ага

* EXPLAIN (BUFFERS) revealed that Visibility Map is never being frozen, as autovacuum ignores append-only never-updated never-deleted table that is only truncated once a day. No way to force autovacuum on such table exists.

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

если в таблице никогда ничего не стирать, то в неё не приходит autovacuum, и из-за этого не работает index only scan

Сама задумка не посылать туда автовакум неплоха , если бы автовакум не запускал процесс сбора статистики котрая нужна для плана запроса

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

там не нужна статистика, там нужен visibility map

если в таблице никогда ничего не стирать, то в неё не приходит autovacuum, и из-за этого не работает index only scan

А если одну запись искусственно обновить теми же самыми данными, то придет?

за статистикой как раз приходит

ну да , сорри , я ее имел ввиду

А если одну запись искусственно обновить теми же самыми данными, то придет?

его и руками можно позвать. но вот только он начинает целиком делать полный скан по всему индексу, чтобы отчистить его от удалённых таплов, а их не было

и получается лишнее чтение на кучу гигабайт

вот вот

вот вот

а можно это "вот вот" в хакерс написать? :)

и получается лишнее чтение на кучу гигабайт

Ну допустим пофиг на это чтение. После него index only заработает?

да

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

http://bitnine.net/blog-useful-information/index-only-scan-and-visibility-map-22/?ckattempt=3

вот тут подробне об этом расказывается

может ктониб обьяснить простым языком, по какому принципу валы пишуться? если например с момента записи прошлого сегмента вал произошла одна малюсенькая транзакция, то она запишется в новый сегмент размером 16 мб? или просто создается файл размером 16 мег, и туда пишутся постепенно все трангзакции пока он не "заполнится" а в случае с потоковой репликацией слейв вытягивает из сегмента транзакции так же постепенно со смещением в этом файле, или он тащит весь сегмент? постгрес про доку читал, но до конца не понял

Есть время сброса вал . И все что за это время набралось скинется в 16МБ файл даже если это 1 транзакция

а я думал раз этио журнал упреждающей записи, то в него данные скинутся перед фиксацией транзакции, а время сброса применимо к чекпойнтам, когда данные скидываются непосредственно в файлы таблиц.. хм..

Есть время сброса вал . И все что за это время набралось скинется в 16МБ файл даже если это 1 транзакция

есть грубо говоря если в течении 5 минут между сбросами была одна транзакция, она не успела скинутся в вал, и база падает, то мы эту транзакцию теряем?

https://postgrespro.ru/docs/postgresql/9.4/runtime-config-wal

я боюсь наврать в объяснениях , поэтому дам ссылку

я боюсь наврать в объяснениях , поэтому дам ссылку

я это читал, потому и попросил обьяснить простым языком, тк до конца не понял )

а я думал раз этио журнал упреждающей записи, то в него данные скинутся перед фиксацией транзакции, а время сброса применимо к чекпойнтам, когда данные скидываются непосредственно в файлы таблиц.. хм..

По-моему, так и работает

я это читал, потому и попросил обьяснить простым языком, тк до конца не понял )

на сколько я понял , запись транзакций идет постоянно в вал лог , но если туда запишется всего одна транзакция за определенный промежуток времени выставленный в настроках то все равно он будет занимать 16 мег

Специальный фоновый процесс checkpointer автоматически выполняет контрольную точку с заданной частотой. Контрольная точка выполняется через каждые checkpoint_segments сегментов журнала или каждые checkpoint_timeout секунд, в зависимости от того, какое событие наступит первым. Значения по умолчанию — 3 сегмента и 300 секунд (5 минут). Если с предыдущей контрольной точки ни один файл WAL так и не был записан, то новые контрольные точки будут пропущены, даже если наступил checkpoint_timeout. (Если используется архивирование WAL и вы хотите управлять частотой смены файлов журнала для ограничения потенциальной потери данных, то нужно корректировать параметр archive_timeout, а не параметры контрольной точки). Также возможен принудительный запуск контрольной точки с помощью SQL-команды CHECKPOINT

Снижение количества checkpoint_segments и/или checkpoint_timeout приводит к более частому созданию контрольных точек. Это позволяет ускорить восстановление после краха (поскольку для воспроизведения нужно меньше данных).

на сколько я понял , запись транзакций идет постоянно в вал лог , но если туда запишется всего одна транзакция за определенный промежуток времени выставленный в настроках то все равно он будет занимать 16 мег

вот я прихожу к тому же мнению. я к чему это все спрашиваю, мне важно выяснить какой максимальный обьем данных я могу потерять при потоковой репликации, в случае повышения слэйва до мастера. прихожу к выводу что можно ориентироваться на данные задержки репликации

да

Ребят, чем проще и удобнее создавать партиции по расписанию? И что скажете о pg_pathman?

Используем партман

Жалоб нет

Добрый вечер. Уже огромное количество времени убил. Никак не получается победить pgbouncer (auth_type = hba, auth_query). Кто нибудь настраивал ? Буду очень признателен если кто поможет. (думаю лучше в личку, чтобы тут не флудить)

Всем привет. Хелп. Почему idea кричит, что такое бд нет, а постгрес ее показывает?

idea пытается зайти по сети, а база открыта только по сокету

см pg_hba.conf

Всем привет. Хелп. Почему idea кричит, что такое бд нет, а постгрес ее показывает?

Вы задаете имя базы postgres/mydb, а не mydb

ERROR: S client not available

Вы задаете имя базы postgres/mydb, а не mydb

Емае) спасибо огромное)

Вы задаете имя базы postgres/mydb, а не mydb

Я бы еще пол ночи просидел) спасибо большое)

У меня в таблице два поля segment_id и product_id. Я туда заношу записи в определенном порядке. Так вот когда я их селектом тяну они мне возвращаются отсортированные по segment_id и product_id. Но то в каком порядке я их заносил, я смотрю им плевать. Получается единственный способ решить это это добавить автоинкремент id?

Насколько я знаю, SELECT без указания ORDER BY не гарантирует порядка. Если вам нужен определенный порядок -- делайте ORDER BY

насколько я знаю, база ничего не знает о том что первым её пришло, а что последним. Или нет?

У меня в таблице два поля segment_id и product_id. Я туда заношу записи в определенном порядке. Так вот когда я их селектом тяну они мне возвращаются отсортированные по segment_id и product_id. Но то в каком порядке я их заносил, я смотрю им плевать. Получается единственный способ решить это это добавить автоинкремент id?

created_at timestamptz default now()

Вопрос спецам по датагрипу. У меня в БД 100500 мульёнов схем. Датагрип видит только публик. Бобёр видит все. Коннект - одним и тем же пользователем? Это побеждается, или как?

Раскрой коннект -> Schemas.. -> All schemas

кстати, ребят, кто-нибудь уже щупал dbForge?

Спасибо. Только вот данный факт - весьма удручающий, ибо большинство схем - рабочие, и дополнительные телодвижения - грусть, печаль, тоска, тлен и безысходность.

@Chuguniy заведи тикет

created_at timestamptz default now()

Проблема в том что из этой базы берут данные из разных проектов. Мне нужно чтобы все они волшебным образом получали отсортированные данные. Если я просто добавлю created_at, то если везде не добавят orderBy, насколько я понимаю оно будет по прежнему тянуться?

Проблема в том что из этой базы берут данные из разных проектов. Мне нужно чтобы все они волшебным образом получали отсортированные данные. Если я просто добавлю created_at, то если везде не добавят orderBy, насколько я понимаю оно будет по прежнему тянуться?

ну, если программисты профессионалы, они добавят order by в те места, в которых нужно

ну, если программисты профессионалы, они добавят order by в те места, в которых нужно

или сделать вьюшку

сделать вьюшку не научит программистов формулировать запросы, и создаст перформанс-проблемы из-за сортировок где не надо

ну, если программисты профессионалы, они добавят order by в те места, в которых нужно

Если данные инсертятся в одном запросе? У них не будет одинаковый created_at?

короче неправильная архитектура порождает костыли

короче неправильная архитектура порождает костыли

это понятно, я думаю как выкрутиться)

Если данные инсертятся в одном запросе? У них не будет одинаковый created_at?

конечно, будет. а у них не одинаковый created_at?

сделать вьюшку не научит программистов формулировать запросы, и создаст перформанс-проблемы из-за сортировок где не надо

Ты не понял: сделать вьюшку, в которой будет order by random Тогда они рано или поздно поймут, что добавлять order by нужно.

это понятно, я думаю как выкрутиться)

истина где-то посередине. думаю договариваться с программистами тоже придется. выставить ишьюсы им всем для начала в гит(лаб|хаб)

Второе: у бобёра, когда активна вкладка "procedures", клик правой кнопкой мыши выдаёт окошко в котором один из пунктов: "Create procedures", соответственно, дальше генерится SQL создания пустой ф-ии, возвращающей INT-вое значение. Такой радости в Datagripe я не вижу. И гугель ничего внятного по этому поводу не выдаёт.

@Chuguniy заведи тикет

если будет принято решение о покупке. В противном случае у меня нет ни времени, ни желания, если честно. Меня бобёр устраивает.

если есть время поныть в чатик, есть время завести тикет

вещи одного порядка

не купишь - придёшь через год перепосмотреть, а оно и сделано

не купишь - придёшь через год перепосмотреть, а оно и сделано

Сделают, буду посмотреть, если желание будет. Пока что для человека, все запросы которого до этого полностью удовлетворялись psql-ем (ну и ER-диаграммы в pgadmin-е, их тоже не стоит сбрасывать со счетов), по части наглядности, логичности и понятности dbeaver существенно предпочтительнее datagrip-а. А с учётом того, что есть ещё кандидаты на рассмотрение... В общем, буду дальше ковырять.

есть такая штука, причинно-следственные связи обычно, если не рассказывать о проблеме тем, кто в состоянии с ней что-то сделать, с проблемой ничего не делается :) особенно учитывая, что разработчики по конференциям ходят и у всех спрашивают, что им сделать и чего вам не хватает

??