Всем привет. Подскажите плиз, почему по той таблице, по тому

же плану с тем же индексом, по тому же условию и с тем же количеством строк (ноль строк!)
Если в запрос добавить второй LEFT JOIN, то
BitmapIndexScan начинает работать в 1800 раз медленнее?
(обратите внимание, что function scan для этого джойна в плане находится гораздо позже)

Ноль строк в результате:
https://explain.depesz.com/s/ayqq - один джойн
https://explain.depesz.com/s/GsAR - два джойна

1370 строка в результате:
https://explain.depesz.com/s/IQfT - один джойн
https://explain.depesz.com/s/rLCp - два джойна

0 строк, текстовый план:
https://explain.depesz.com/s/0rYv -- один джойн
https://explain.depesz.com/s/FtqW — два джойна

1370 строк, текстовый план:
https://explain.depesz.com/s/uvUg — один джойн
https://explain.depesz.com/s/WATZ — два джойна
Сервер версии 13.1

#konkove #proposition

Подскажите плиз, почему Вы продолжаете публиковать JSON plans, хотя Вас уже (не раз?) просили этого не делать? ;)

Дополнил explain

Такие опции в рекомендациях на сайтах: https://explain.dalibo.com/ http://tatiyants.com/pev/#/plans/new а на depesz нет примера рекомендуемых опций (((

Напомните пожалуйста опции 😇 и я заодно напишу depesz в обратную связь ** всё. нашел в чате: EXPLAIN( ANALYSE, COSTS, VERBOSE, settings, buffers )

И что? Я же уже Вам писал, почему так лучше — я читаю текстовые планы, например. А то, что показывает https://explain.depesz.com в таком случае — это результат конвертации, которая может быть неправильной (в т.ч. неполной).

"Максимальные" для SELECT-ов в используемой Вами версии — это EXPLAIN (ANALYZE, VERBOSE, BUFFERS, SETTINGS). default COSTS = true, кстати.

Yaroslav добавил ссылки на текстовый план Спасибо за замечания

Спасибо, я посмотрю...

Хмм... а точно первый план был с BUFFERS? Потому что такое, например, в нём есть: -> Bitmap Index Scan on order_id_sys_period_app_period_excl (cost=0.00..4.86 rows=33 width=0) (actual time=0.412..0.412 rows=0 loops=1) Index Cond: ((o.sys_period @> sys_time()) AND (o.app_period && $3)) А shared hit вообще нет. Или эта таблица (и т.д.) на самом деле пустая?

Все планы точно с buffers

buffers, кастати есть. Посмотрите плиз https://explain.depesz.com/s/FtqW#l1 почему его нет ниже - это вопрос. ммм, видимо да. Отсутвие buffers походу замедляет выполнение запроса. И почему же buffers нет для остальных планов? )

Нет, совсем их нет при выполнении запроса. Только при планировании, и это как-то странно.

Потому, что после шэсти повторений воззвания к _app_period() в запросе постгрес решыл запустить JIT и тот работал секунду. То, что его отнесли к первому скану -- это артэфакт показа планов. ЗЫ И да, вы так не делайте (c). Вот серьёзно, вопрос с JIT-то решыть можно, конечно, запретом например -- но сам по себе веер одинаковых нематериализованных вызовов табличной функцыи выглядит крайне эклектично.

> Потому, что после шэсти повторений воззвания к _app_period() в запросе постгрес решыл запустить JIT и тот работал секунду. Хмм... почему Вы думаете, что решение о запуске JIT вообще от этого зависит?

да, спасибо. 👍

Потому, что во-первых это логично, во-вторых -- это вообще одно из немногих отличий запросов, которые могли к нему привести.

Не вижу логики. Вы какой JIT имеете в виду? Если в основном запросе, то он не prepared, т.е. JIT от количества запусков не зависит. Если внутри функций, то при стандартных настройках JIT все использованные функции явно обрабатываться не будут.

Впрочем, Вы правы. В данном случае он запускается скорее из-за того, что планнер считает, что ещё один join acc_ready увеличит результат в 500 раз и всё всё равно будет выполняться десятками секунд.

И да, там вряд ли стандартные настройки JIT.

Да, я тоже так прочитал план. > И да, там вряд ли стандартные настройки JIT. Стандартные. Это EXPLAIN( ANALYSE, COSTS, VERBOSE, SETTINGS, BUFFERS), обратите внимание.

Там Jit занимает 750мс. На тот join на самом деле ушло дополнительно 350мс. А проблема тут ещё в другом, что кардинальность сильно не сходится. А из-за этого оптимальный план может быть другим. Я бы вначале запрос с определением app_period выполнил отдельно, подставив его результат в второй CTE, и посмотрел на результат.