т.е. если я задаю значение сбора статистики 100, у меня размер массива становится 100. При увеличении значения растет размер массива, соотв. что это значит при выполнении команды analyze? Количество анализируемых в таблице строк не уменьшитя? просто больше их сохранится в массивах?

а планы разве не на основе гистограмм строятся?

На основе гистограмм и MCV.

количество анализируемых строк не зависит от параметра set statistics? от этого зависит только итоговое число сохраненных в массивах значений?

И показали бы вы индексы, запрос и план... Какая версия PostgreSQL, кстати?

10.4

т.е. если я задаю значение сбора статистики 100, у меня размер массива становится 100. При увеличении значения растет размер массива, соотв. что это значит при выполнении команды analyze? Количество анализируемых в таблице строк не уменьшитя? просто больше их сохранится в массивах?

When performing ANALYZE, the number of rows to sample is determined as (300 * statistics_target)

/src/backend/statistics/README

SELECT foo FROM table WHERE bar = '1111111-1111-1111-1111-11111111111' and baz = 'SOME__NONSELECTIVE_STATUS' AND bad_func(dar) = '111111'; create index idx_bar_bad ON table (bad_func(dar), bar) WHERE ((baz) = 'SOME__NONSELECTIVE_STATUS');

функция immutable

When performing ANALYZE, the number of rows to sample is determined as (300 * statistics_target)

спасибо! выходит самплов будет по факту 3 000 000 собираться и этого все равно не хватает

SELECT foo FROM table WHERE bar = '1111111-1111-1111-1111-11111111111' and baz = 'SOME__NONSELECTIVE_STATUS' AND bad_func(dar) = '111111'; create index idx_bar_bad ON table (bad_func(dar), bar) WHERE ((baz) = 'SOME__NONSELECTIVE_STATUS');

Так, а вы (VACUUM) ANALYZE после создания этого индекса делали?

Да

выкрутил по полям bar, dar статистику и по полю индекса

спасибо! выходит самплов будет по факту 3 000 000 собираться и этого все равно не хватает

А сколько rows в таблице? И, тем не менее, посмотрите правдоподобности оценок по одной этой функции в планах. Т.е. "WHERE bad_func(dar) = '111111'";

после этого прогнал vacuum analyze

rows=178970288

данные распределены так, что под топ100 значений bar попадает около 80% всей таблицы, а на остальные десятки тысяч значений около 20%

соотв, все проблемы начинаются с запросом тогда, когда значение берется из топ100

А сколько rows в таблице? И, тем не менее, посмотрите правдоподобности оценок по одной этой функции в планах. Т.е. "WHERE bad_func(dar) = '111111'";

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

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

Зачем? Он у вас уже есть, разве нет?

нет, есть только составной

все вариации запроса всегда идут с комбинацией bar + bad_func(dar)

нет, есть только составной

Это, насколько я помню, неважно.

вроде, это не важно в обратную сторону. Тогда пойдут битмапы

а из составного индекса значения не выдернутся

а из составного индекса значения не выдернутся

Нет, стоп. Мы говорим только об оценках, не об executor-е.

да, в таком случае не так важен отдельный индекс скорее всего

неправильно понял

все вариации запроса всегда идут с комбинацией bar + bad_func(dar)

Попробуйте хотя бы просто EXPLAIN (без ANALYZE). Т.е. сравнить "WHERE bar + bad_func(dar)" с "WHERE bad_func(dar)".

Именно оценки кол-ва rows.

rows=178970288

Да, это sample size меньше 2%, не очень-то густо... Тем не менее, вероятность собрать более-менее нормальные гистограммы и MCV, как ни удивительно, довольно высока. ;)

rows=14952 с тремя условиями, rows=894851 с одним (по оценке)

в первом случае фактически возвращается 1 строка, а не 15к строк во втором сейчас проверяю, но тоже скорее всего не 900к строк

rows=14952 с тремя условиями, rows=894851 с одним (по оценке)

С одним — это именно с "WHERE bad_func(dar)"?

да

да

В общем, проверьте оценки по этим условиям независимо. А потом уже надо что-то думать...

да, все еще хуже, чем с первым

фактически нашел 2 строки, а оценка в 900к строк

фактически нашел 2 строки, а оценка в 900к строк

Показали бы вы EXPLAIN-ы... отдельно для каждого из условий, и по трём вместе. С ANALYZE, конечно, интереснее (если это возможно).

По всем трем

И для разных констант (с выской и низкой селективностью) — тоже бы не неплохо.

только по одному

А тип результата у bad_func() какой?

varchar(64)

у поля dar тоже

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

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

разница во времени выполнения пол минуты и больше

у поля dar тоже

Подождите, что-то тут не то, мне кажется (как-то он совсем промахивается в оценке... не должно такого быть).

да, вполне вероятно что-то не так и у меня руки кривые ?

тоже кажется такой промах очень странным

тоже кажется такой промах очень странным

А с любым другим значением константы для запроса по функции что будет?

0 строк фактически, примерно такой-же результат в 14-15к в оценке и быстрое время выполнения

Buffers: shared hit=3 read=2

по структуре план такой же

0 строк фактически, примерно такой-же результат в 14-15к в оценке и быстрое время выполнения

Покажите план, с какой-нибудь "редкой" и "частой" костантами. Формы планов, время выполнения и т.п. сейчас вообще не имеют значения.

это планы по редким bar по частому выше немного кидал как-раз

Первый - частый (в плане много строк с таким bar), второй и третий редкие

в целом, по бизнесу запроса во всех случаях может вернуться или 1 или 0 строк

это планы по редким bar по частому выше немного кидал как-раз

Да это не то. :( Лучше по одному конкретному условию — так трудно что-то анализировать. Т.е. здесь перемножены какие-то селективности, а какие — кто его знает... Трудно угадать по данному X (=a*b) угадать a и b. ;)

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

Да это не то. :( Лучше по одному конкретному условию — так трудно что-то анализировать. Т.е. здесь перемножены какие-то селективности, а какие — кто его знает... Трудно угадать по данному X (=a*b) угадать a и b. ;)

сейчас посмотрю

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

Да неважно долгое выполнение. ;) Вы с оценками разберитесь.

Пока не разберётесь (если это вообще возможно), вы просто наблюдаете за тем, как планировщик "подбрасывает монету" (и ему когда-то везёт), понимаете? ;)

ERROR: S client not available

Пока не разберётесь (если это вообще возможно), вы просто наблюдаете за тем, как планировщик "подбрасывает монету" (и ему когда-то везёт), понимаете? ;)

потому и пытаюсь разобраться с костами ?

Ясно, а насколько эти оценки близки к реальности (хотя бы примерно)?

сейчас вот жду завершения запросов

довольно точые оценки

Для частого он оценивает ~ 2%, так? И у вас распределение частых значений примерно такое и есть?

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

Для частого он оценивает ~ 2%, так? И у вас распределение частых значений примерно такое и есть?

да, примерно так

довольно точые оценки

Так, это хорошо. А отдельно для функции?

это значения, соответсвующие частому и редкому bar (они взаимосвязаны)

по функции сложно сказать частые и редкие значения и их распределение отдельно от bar

и посчитать фактическое значение тоже будет сложнее, тк нет индекса отдельного

а что мешает создать несколько индексов?

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

это значения, соответсвующие частому и редкому bar (они взаимосвязаны)

Ага, стоп, вот это, похоже, косяк (оценки-то 1:1!). Попробуйте пару любых других.

и посчитать фактическое значение тоже будет сложнее, тк нет индекса отдельного

А что сложного? EXPLAIN ANALYZE, и некоторое время спустя... вы их знаете. :)

Ага, стоп, вот это, похоже, косяк (оценки-то 1:1!). Попробуйте пару любых других.

те же ожидаемые значения вернул

rows=894851

А что сложного? EXPLAIN ANALYZE, и некоторое время спустя... вы их знаете. :)

работаю над этим ))

те же ожидаемые значения вернул

Что как бы намекает нам, что никакая это не статистика, а default estimate (0.5%). И это — проблема.

проверил без функции тоже наугад

там тоже везде значения совпадают

хотя rows=9 (тоже везде)

в плане только по dar полю без функции (которая по сути нормализует строки)

работаю над этим ))

Селективность как-то очень похожа на 0.5%. Есть другие варианты констант? ;)

наугад подставил 20 значений из первых 4000 совпадает везде

одинаковые выскоие rows для функции одинаковые низкие rows для поля без вызова функции

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

и в случае вызова без функции по нему идет план - индекс скан

одинаковые выскоие rows для функции одинаковые низкие rows для поля без вызова функции

Да забудьте вы о всём остальном, кроме функции (не прыгайте, разберитесь с ней)!

и в случае вызова без функции по нему идет план - индекс скан

Ещё раз, формы плана сейчас неинтересны. Я вам уже писал про кидание монеты, нет? ;)

да, если смотреть с любыми рандомными значениями (Пока что) – всегда константное число возвращаемых строк