EB
Yaroslav Schekin
Хотя бы 1000. Можно и 10000.
10к помогло) Это норм практика тюнить этот параметр?
Size: a a a
2020 May 20
YS
10к помогло) Это норм практика тюнить этот параметр?
В принципе, да. Но увлекаться не стоит — это замедляет как ANALYZE, так и планирование.
Т.е. Вы могли бы теперь попробовать 1000, например, и, если хватит, так и оставить (но лучше посмотреть и планы, в принципе).
Т.е. Вы могли бы теперь попробовать 1000, например, и, если хватит, так и оставить (но лучше посмотреть и планы, в принципе).
EB
Yaroslav Schekin
В принципе, да. Но увлекаться не стоит — это замедляет как ANALYZE, так и планирование.
Т.е. Вы могли бы теперь попробовать 1000, например, и, если хватит, так и оставить (но лучше посмотреть и планы, в принципе).
Т.е. Вы могли бы теперь попробовать 1000, например, и, если хватит, так и оставить (но лучше посмотреть и планы, в принципе).
Yaroslav, спасибо! Последний вопрос. У меня сейчас в базе 1M строк. В теории, если я выставлю 1к и это сейчас поможет, то на 50M может опять поломаться?
YS
Yaroslav, спасибо! Последний вопрос. У меня сейчас в базе 1M строк. В теории, если я выставлю 1к и это сейчас поможет, то на 50M может опять поломаться?
Да, может. А может и не поломаться, что скорее всего (зависит от распределения данных).
PC
Коллеги, pg_pathman отлично умеет создавать партиции по дате сам без необходимости их руками нарезать. У posgres pro написано, что pg_pathman deprecated и пользуйтесь нативным партиционированием. Так вот вопрос: а как нативно сделать так, чтоб postgres сам создавал партиции без необходимости каждое первое число посреди ночи лезть в базу и создавать новую партицию на месяц?
AB
Коллеги, pg_pathman отлично умеет создавать партиции по дате сам без необходимости их руками нарезать. У posgres pro написано, что pg_pathman deprecated и пользуйтесь нативным партиционированием. Так вот вопрос: а как нативно сделать так, чтоб postgres сам создавал партиции без необходимости каждое первое число посреди ночи лезть в базу и создавать новую партицию на месяц?
1. создай заранее
2. сделай вызов процедуры создания в чем-то типа pg_cron
2. сделай вызов процедуры создания в чем-то типа pg_cron
PC
То есть условно механизма, который был в pg_pathman и помогал избавиться от этой проблемы - нет - нужно самому костылить под каждую табличку?
YS
Коллеги, pg_pathman отлично умеет создавать партиции по дате сам без необходимости их руками нарезать. У posgres pro написано, что pg_pathman deprecated и пользуйтесь нативным партиционированием. Так вот вопрос: а как нативно сделать так, чтоб postgres сам создавал партиции без необходимости каждое первое число посреди ночи лезть в базу и создавать новую партицию на месяц?
Для этого есть pg_partman (или pg_cron и т.п., на худой конец).
И какая Вам разница, "нативно" или нет — pg_pathman Вы же пользовались? ;)
И какая Вам разница, "нативно" или нет — pg_pathman Вы же пользовались? ;)
YS
Привет!
https://bit.ly/3bMORLR
Апдейт падает в зависимости от порядка строк в базе.
Есть ли какой-то способ решить эту проблему?
Например, задав порядок апдейта строк?
Хочется одним запросом занулить существующий флаг и выставить новый по хитрому правилу.
https://bit.ly/3bMORLR
Апдейт падает в зависимости от порядка строк в базе.
Есть ли какой-то способ решить эту проблему?
Например, задав порядок апдейта строк?
Хочется одним запросом занулить существующий флаг и выставить новый по хитрому правилу.
Курсоры-то тут точно помогут... А иначе — не знаю, зависит от "хитрого правила". ;)
E
Yaroslav Schekin
Курсоры-то тут точно помогут... А иначе — не знаю, зависит от "хитрого правила". ;)
Давайте рассматривать текущий кейс, где я просто пытаюсь инвертировать флаг is_admin.
E
Хитрые правила тут до лампочки, мне хочется просто понять, как решить проблему того, что уникальность индекса проверяется для каждой строки, а не для результата запроса.
PC
Yaroslav Schekin
Для этого есть pg_partman (или pg_cron и т.п., на худой конец).
И какая Вам разница, "нативно" или нет — pg_pathman Вы же пользовались? ;)
И какая Вам разница, "нативно" или нет — pg_pathman Вы же пользовались? ;)
Меня печалит тот факт, что pg_partman deprecated и указано - пользуйтесь нативным. А в нативном функционала нет. Например в какой-то момент времени обновят бд на условную 14 или 15 - и не взлетит, т.к. deprecated. А разработка про условный сервис юзающий условную бд уже забыла очень давно...
E
В итоге 'update set flag = not flag' выдаёт duplicate key при том, что конечный результат запроса всё же уникален.
YS
Меня печалит тот факт, что pg_partman deprecated и указано - пользуйтесь нативным. А в нативном функционала нет. Например в какой-то момент времени обновят бд на условную 14 или 15 - и не взлетит, т.к. deprecated. А разработка про условный сервис юзающий условную бд уже забыла очень давно...
Нет, он не deprecated — это совершенно другой проект (внимательнее читайте названия). ;)
PC
о, пойду смотреть, спасибо.
L
Друзья, разыскивается sql программист, который умеет читать планы и писать правильный код. компания: wildberries
условия: фулл-тайм / парт-тайм / удаленка, 60-120 тр на руки
Собеседование готов провести хоть сейчас, писать в телеграм @avelestat
условия: фулл-тайм / парт-тайм / удаленка, 60-120 тр на руки
Собеседование готов провести хоть сейчас, писать в телеграм @avelestat
.P
Никакой мистики тут нет. Есть обычная ошибка оптимизатора из-за неправильной оценки селективности. В результате выбирается nested loop
Nested Loop (cost=1.71..56.22 rows=2 width=336) (actual time=0.119..3044.548 rows=860360 loops=1)
Думали, что выберем 2 записи, а выбрали почти миллион. Ничего себя так ошиблись?
Это, к сожалаению, больная мозоль постгреса. Он очень плохо учитывает корреляцию между колонками.
Что можно сделать?
1. запретит nested loop (/в данном случае не поможет)
2. создать составную (многоколоночную) статистику: тут главное понять для каких колонок её надо создать. Как подсказку можете ориентироваться на составные индексы, которые у вас есть. У нас в ПгПро используется патч для постгреса, которые неявно создаёт статистику по составным индексам. Для 1С запросов очень помогает.
3ю поиграть с параметрами оптимизатора, заставив его выбрать правильный план. Это очень не тривиальная задача.
3. Использовать расширения типа AQO,которые с помощью ML могут сами подправить селективность
Nested Loop (cost=1.71..56.22 rows=2 width=336) (actual time=0.119..3044.548 rows=860360 loops=1)
Думали, что выберем 2 записи, а выбрали почти миллион. Ничего себя так ошиблись?
Это, к сожалаению, больная мозоль постгреса. Он очень плохо учитывает корреляцию между колонками.
Что можно сделать?
1. запретит nested loop (/в данном случае не поможет)
2. создать составную (многоколоночную) статистику: тут главное понять для каких колонок её надо создать. Как подсказку можете ориентироваться на составные индексы, которые у вас есть. У нас в ПгПро используется патч для постгреса, которые неявно создаёт статистику по составным индексам. Для 1С запросов очень помогает.
3ю поиграть с параметрами оптимизатора, заставив его выбрать правильный план. Это очень не тривиальная задача.
3. Использовать расширения типа AQO,которые с помощью ML могут сами подправить селективность
Коллеги, добрый вечер. И снова я со своим уже не таким "мистическим" запросом. :)
Мои попытки посоздавать разные статистики благополучно провалились, но зато внезапно действительно помогло это расширение AQO. Результат попахивает магией, но для "мистического запроса" самое то :)
Мои попытки посоздавать разные статистики благополучно провалились, но зато внезапно действительно помогло это расширение AQO. Результат попахивает магией, но для "мистического запроса" самое то :)
.P
Результаты:
psql (12.1)
query (немного отличается, наверное из-за другой версии DBD::Pg):
Результат до оптимизации с помощью AQO: https://explain.depesz.com/s/CIdF
Результат после оптимизации: https://explain.depesz.com/s/b76v
Если интересны какие-нибудь тесты-запросы, готов сегодня погонять, пока база жива :)
И большое спасибо всем поучаствовавшим!
psql (12.1)
query (немного отличается, наверное из-за другой версии DBD::Pg):
SELECT DISTINCT main.* FROM Users main CROSS JOIN ACL ACL_3 JOIN Principals Principals_1 ON ( Principals_1.id = main.id ) JOIN CachedGroupMembers CachedGroupMembers_2 ON ( CachedGroupMembers_2.MemberId = Principals_1.id ) JOIN CachedGroupMembers CachedGroupMembers_4 ON ( CachedGroupMembers_4.MemberId = Principals_1.id ) WHERE ((ACL_3.ObjectType = 'RT::Queue' AND ACL_3.ObjectId = 55) OR (ACL_3.ObjectType = 'RT::System' AND ACL_3.ObjectId = 1)) AND (ACL_3.PrincipalId = CachedGroupMembers_4.GroupId) AND (ACL_3.PrincipalType = 'Group') AND (ACL_3.RightName = 'OwnTicket' OR ACL_3.RightName = 'SuperUser') AND (CachedGroupMembers_2.Disabled = '0') AND (CachedGroupMembers_2.GroupId = '4') AND (CachedGroupMembers_4.Disabled = '0') AND (Principals_1.Disabled = '0') AND (Principals_1.PrincipalType = 'User') AND (Principals_1.id != '1') ORDER BY main.Name ASC
Результат до оптимизации с помощью AQO: https://explain.depesz.com/s/CIdF
Результат после оптимизации: https://explain.depesz.com/s/b76v
Если интересны какие-нибудь тесты-запросы, готов сегодня погонять, пока база жива :)
И большое спасибо всем поучаствовавшим!
Р
вопрос по внесению изменений в таблицы с дочерними таблицами.
в заббиксе настроено партицирование, после обновления до последней версии надо внести изменения в базу
по доке
To add a check constraint to a table and all its children:
zipchk?
в заббиксе настроено партицирование, после обновления до последней версии надо внести изменения в базу
ALTER TABLE ONLY trends
ALTER COLUMN value_min TYPE DOUBLE PRECISION,
ALTER COLUMN value_min SET DEFAULT '0.0000',
ALTER COLUMN value_avg TYPE DOUBLE PRECISION,
ALTER COLUMN value_avg SET DEFAULT '0.0000',
ALTER COLUMN value_max TYPE DOUBLE PRECISION,
ALTER COLUMN value_max SET DEFAULT '0.0000';
ALTER TABLE ONLY history
ALTER COLUMN value TYPE DOUBLE PRECISION,
ALTER COLUMN value SET DEFAULT '0.0000';
psql при попытке применения измений пишет, есть дочерние таблицы в них надо внести изменения тоже.по доке
https://www.postgresql.org/docs/12/sql-altertable.html
нашел только это по дочерним таблицам и работы с нимиTo add a check constraint to a table and all its children:
ALTER TABLE distributors ADD CONSTRAINT zipchk CHECK (char_length(zipcode) = 5);To add a check constraint only to a table and not to its children:
ALTER TABLE distributors ADD CONSTRAINT zipchk CHECK (char_length(zipcode) = 5) NO INHERIT;
Подскажите в итоге что надо добавить в запрос, что бы изменения применились на дочерние таблицы?zipchk?
V
Покажите что пишет psql