Я когда впервые увидел проблему с долгим временем планирования при вычислении селективности в джойнах, я тоже пробовал кэшировать детостанные данные на время двойного цикла в eqseljoin. Но применение хэш-поиска сокращает время сильнее. Поэтому на хэш-поиске и остановился. Быть может реально в 'референсном форке' лучше будет.
Отлично. Тогда остается только вторая часть вопроса: кэшируете ли вы статистику (детостированную, распакованную, хэшированную)? Поскольку, как показано в данном примере, 200+ раз делать одно и то же для одной колонки может быть накладно.
Нет, сейчас мы не кэшируем статистику. После перехода на хэш-поиск для сопоставления MCV время планирования заметно сократилось. Фактически основная проблема была решена сменой алгоритма, поэтому мы пока не видим дальнейшие оптимизации целесообразными.
Вижу. Только вы предлагаете сортировать перед сравнением, а я - хранить в отсортированном виде - в данной задаче размер массива не гигантский, но количество переиспользований велико.
На момент написания статьи и в версии 17.6 мы действительно использовали сортировку перед сравнением. Однако сейчас реализован подход, описанный по второй ссылке : мы строим хэш-таблицу по MCV-статистике одного столбца и затем ищем совпадения по значениям MCV другого столбца. После этого изменения сопоставление MCV больше не опирается на вложенные циклы с большим количеством повторных вызовов byteaeq(), и в профилировании его вклад в CPU больше не выделяется.
По умолчанию default_statistics_target = 100. Он определяет максимальное количество элементов в MCV-списке для столбца, если не задано явно через ALTER TABLE ... ALTER COLUMN ... SET STATISTICS.
Алгоритм обхода MCV меняется, когда сумма размеров MCV-списков двух соединяемых столбцов становится больше или равна 200. То есть патч сработает, если оба столбца в условии JOIN имеют MCV-списки максимального размера, то есть 100 элементов каждый.
По оптимизации "Ускорение планирования запросов при высоких значениях default_statistics_target" на текущий момент идет обсуждение смены алгоритма обхода MCV (https://commitfest.postgresql.org/patch/5929/)
Я когда впервые увидел проблему с долгим временем планирования при вычислении селективности в джойнах, я тоже пробовал кэшировать детостанные данные на время двойного цикла в eqseljoin. Но применение хэш-поиска сокращает время сильнее. Поэтому на хэш-поиске и остановился. Быть может реально в 'референсном форке' лучше будет.
Скидываю код с хэш-поиском
Нет, сейчас мы не кэшируем статистику. После перехода на хэш-поиск для сопоставления MCV время планирования заметно сократилось. Фактически основная проблема была решена сменой алгоритма, поэтому мы пока не видим дальнейшие оптимизации целесообразными.
На момент написания статьи и в версии 17.6 мы действительно использовали сортировку перед сравнением. Однако сейчас реализован подход, описанный по второй ссылке : мы строим хэш-таблицу по MCV-статистике одного столбца и затем ищем совпадения по значениям MCV другого столбца. После этого изменения сопоставление MCV больше не опирается на вложенные циклы с большим количеством повторных вызовов
byteaeq(), и в профилировании его вклад в CPU больше не выделяется.По умолчанию
default_statistics_target = 100. Он определяет максимальное количество элементов в MCV-списке для столбца, если не задано явно черезALTER TABLE ... ALTER COLUMN ... SET STATISTICS.Алгоритм обхода MCV меняется, когда сумма размеров MCV-списков двух соединяемых столбцов становится больше или равна 200. То есть патч сработает, если оба столбца в условии
JOINимеют MCV-списки максимального размера, то есть 100 элементов каждый.https://commitfest.postgresql.org/patch/5929/
По оптимизации "Ускорение планирования запросов при высоких значениях default_statistics_target" на текущий момент идет обсуждение смены алгоритма обхода MCV
(https://commitfest.postgresql.org/patch/5929/)