┌─────────────┬──────────┬─────────────┐ │ stanullfrac │ stawidth │ stadistinct │ ├─────────────┼──────────┼─────────────┤ │ 0 │ 13 │ 1.37859e+07 │ └─────────────┴──────────┴─────────────┘

статистика по функциональному индексу

┌─────────────┬──────────┬─────────────┐ │ stanullfrac │ stawidth │ stadistinct │ ├─────────────┼──────────┼─────────────┤ │ 0 │ 13 │ 1.37859e+07 │ └─────────────┴──────────┴─────────────┘

Точно для индекса?

да

вынимал через select stanullfrac,stawidth,stadistinct from pg_statistic where starelid = ‘idx_bar_bad’::regclass

да

Т.е. SELECT * FROM pg_stats WHERE tablename = 'your_index_name'; А гистограммы и MCV там есть?

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

cannot to read file: Invalid argument

в слотах каталога pg_statistic значения какие-то есть

cannot to read file: Invalid argument

Так, это что-то странное... ну а вы superuser?

в слотах каталога pg_statistic значения какие-то есть

А, ну и ладно, в таком случае. А в MCV там что-нибудь есть?

а я, если честно, с ходу не знаю какие там слоты за что отвечают)

они, вроде, через ключи какие-то маппятся

stavalues2, stavalues1 и stanumbers1 заполнены а дальше у меня не хватило лога истории, чтобы все вместить)

они, вроде, через ключи какие-то маппятся

Ну да, это массив ключей. Вот если вы возьмёте любой из них и подставите в свой запрос (просто EXPLAIN), оценка меняется?

stavalues2, stavalues1 и stanumbers1 заполнены а дальше у меня не хватило лога истории, чтобы все вместить)

most_common_vals

не поменялось

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

не значения, а символы в значениях

больше похоже, что это значения из самого поля, а не из функционального индекса

нет, тут не прав

значения от функции

больше похоже, что это значения из самого поля, а не из функционального индекса

Так ещё раз, вы точно ту статистику смотрите? Для самого поля же тоже есть...

значения от функции

100%? ;) И при их подстановке — план показывает всё те же 0.5% rows?

Да

мб статистика по составному функциональному индексу не учитывается?

в моем случае одно поле обычное, второе функциональное

но судя по каталогу все по крайней мере собирается

мб статистика по составному функциональному индексу не учитывается?

Хмм... это странно, но всё должно собираться. А покажите-ка ещё раз запрос с WHERE по функции (может, мы что-то пропускаем)?

В плане текст запроса с фильтром только по функции?

SELECT foo FROM table WHERE bad_func(dar) = '111231';

SELECT foo FROM table WHERE bad_func(dar) = '111231';

А \df+ bad_func можете показать?

CREATE OR REPLACE FUNCTION bad_func(dar character varying) RETURNS character varying LANGUAGE plpgsql IMMUTABLE STRICT COST 1 AS $function$ BEGIN RETURN trim(trailing ' ' from regexp_replace(dar, '^[\s0№#\_]+', '', 'g')); END; $function$;

сама функция

сама функция

Покажите \df+ тоже, на всякий случай.

не совсем понял, для чего? если вы про то, что функция может не совпадать с той, что на сервере – брал текст из \ef

а все остальные поля из \df+ в общем дублируют определение функции, кроме владельца, схемы и тд (те тех параметров, что я все равно не смогу публично передать)

а все остальные поля из \df+ в общем дублируют определение функции, кроме владельца, схемы и тд (те тех параметров, что я все равно не смогу публично передать)

Хорошо... а, я хотел ещё result/argument data types посмотреть. :)

Result data type - character varying Argument data types - dar character varying

Result data type - character varying Argument data types - dar character varying

Так, а вы, всё-таки, superuser? Под ним проверяете (а то там есть всякие ограничения доступа планировщика к "чужой" статистике... не хотелось бы на них наткнуться)?

да, суперюзер

Так, а вы, всё-таки, superuser? Под ним проверяете (а то там есть всякие ограничения доступа планировщика к "чужой" статистике... не хотелось бы на них наткнуться)?

а про ограничения где написано? на сколько я знаю, вроде нет таких ограничений...

Я тут перечитвал сообщения... — > А тип результата у bad_func() какой? varchar(64) у поля dar тоже — Что-то тут не так, или это какая-то другая функция?

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

Я тут перечитвал сообщения... — > А тип результата у bad_func() какой? varchar(64) у поля dar тоже — Что-то тут не так, или это какая-то другая функция?

не так, в плане у самой функции в аргументе не указано ограничение на число символов?

а про ограничения где написано? на сколько я знаю, вроде нет таких ограничений...

Да ладно? ;) Например: https://www.postgresql.org/message-id/1436691547878-5857659.post%40n5.nabble.com (Обратите внимание, кто автор сообщения.) ;) ;)

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

И тем же путём можно было бы (используя EXPLAIN), что-то косвенно "выведать" о чужих значениях, поэтому там и потом что-то "закрывали", если не путаю...

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

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

Ну а я считаю наоборот. Впрочем, раз вы superuser, к делу это не относится (у вас же нет RLS на этой таблице?)...

нет

нет

Хмм... у меня вот работают оценки, основанные на вашей функции (по крайней мере, гистограммные).

Т.е. для < , > и т.п. А у вас тоже (в смысле, как и по равенству) нет?

да, для > выдает тоже константные предсказания

и да, на другом стенде тоже работает нормально ?

и планы другие

но данные отилчаются тоже

и да, на другом стенде тоже работает нормально ?

В смысле? Выдаёт разные оценки? (У меня именно работает, т.е. оценки правдоподобные.)

именно работает

выдает правдоподобные оценки, да

но данные несравнимо разные

Подскажите пожалуйста идёт объявление переменных @tovar @nomer @data А потом Select @tovar=1, @nomer=123, @data=2018 И это без фром Какую роль играет здесь select? Почему присвоение через set просто не написать?

именно работает

WTF?! ;) Хмм... интересно, какая между стендами разница?

Подскажите пожалуйста идёт объявление переменных @tovar @nomer @data А потом Select @tovar=1, @nomer=123, @data=2018 И это без фром Какую роль играет здесь select? Почему присвоение через set просто не написать?

Это не PostgreSQL.

отставание по времени на пол года или около того в данных

ERROR: S client not available

на том, что работает данные за полгода в прошлом

хотя я проверял там не так детально хотел воспроизвести, получил адекватные косты и планы и ушел оттуда )

версии постгреса и там и там совпадают

но не совпадает все остальное ) конфиги, железо, мощности, данные и тд

хотя я проверял там не так детально хотел воспроизвести, получил адекватные косты и планы и ушел оттуда )

А что, если сделать дамп схемы (или этой таблицы), и сравнить? А то это уж вовсе какая-то мистика... ;) Хотя, надо ещё подумать... Т.е. на другом стенде для > выдает разные (более-менее корректные) предсказания? А на этом константы?

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

на другом стенде немного другие, но константы

и с > тоже константы

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

Фу, а то я уж поразился. ;)

хоть что-то объяснилось ?

хоть что-то объяснилось ?

А вы можете воспроизвести это на минимальном примере? Т.е. взять и сделать "копию" схемы этой таблицы, повыкинуть оттуда не относящиеся к делу поля, залить туда немного (INSERT INTO ... SELECT ... FROM orig_table LIMIT 1000000;) данных из оригинальной, создать аналогичный индекс, сделать VACUUM ANALYZE, и проверить оценки? Дело-то всё в том, что у меня всё работает, на той же версии PostgreSQL. :(

Попробую

Правда, распределение сильно изменится

Правда, распределение сильно изменится

Да это ясно, но сейчас у вас статистика вообще не используется — так не должно быть.

Не должно))

Минут через 30 скину результат

Не должно))

Т.е. у вас всё ведёт себя так, как будто статистики вообще нет. Смотрите: CREATE OR REPLACE FUNCTION public.random_text(length integer) RETURNS text LANGUAGE sql AS $function$ SELECT string_agg(chr(ascii('A') + (random() * 25)::integer), '' ORDER BY n) FROM generate_series(1, $1) AS t(n); $function$; CREATE TABLE test_func AS SELECT g.n, CAST(random_text(20) AS character varying) AS random_text FROM generate_series(1, 100000) AS g(n); CREATE INDEX ON test_func(bad_func(random_text)); EXPLAIN SELECT * FROM test_func WHERE bad_func(random_text) = 'dsadsada'; — Bitmap Heap Scan on test_func (cost=16.29..719.98 rows=500 width=25) Обратите внимание, это default selectivity (0.5%). После чего: VACUUM ANALYZE test_func; И в плане получается корректная оценка: — Index Scan using test_func_bad_func_idx on test_func (cost=0.42..8.44 rows=1 width=25)

добрался до ноута

да, первая часть как у вас

при создании без аналайза дефолтная селективность

после аналайза то же самое

дефолтная селективность

а, стоп

у вас индекс отличается

я строил аналогичный своему кейсу составной функциональный индекс с условием

а у вас в тесте просто функциональный

построил функциональный индекс и бинго ? оно заработало

мб статистика по составному функциональному индексу не учитывается?

пока на это похоже

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

по результатам напишу

у вас индекс отличается

А, да, перепутал. ;) Но с составным у меня тоже работает.