Ускоряем запросы в PostgreSQL, оптимизируя оператор GROUP BY

[redfox0]

Патчи были предложены в upstream?

[danolivo]

В начале ссылка была:

https://www.postgresql.org/message-id/flat/8742aaa8-9519-4a1f-91bd-364aec65f5cf%40gmail.com

[lazy_val]

В сортируемом кортеже 4 колонки (CustomerId, CategoryId, WeekDay, Total), а Postgres вызывает оператор сравнения отдельно для каждой пары значений — максимум 4 раза

А разве Postgres не сортирует кортежи целиком? Abbreviated keys, вот это все

[danolivo]

Abbreviated keys предназначено для ускорения сортировки и не уменьшает количество операций сравнения. Это скорее вопрос коэффициентов в формуле стоимости операции. Сама по себе оптимальная расстановка колонок в группировке хуже не сделает. А вот лучше может.

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

[phpguider]

Here's how you can handle your queries more efficiently by using partitions in PostgreSQL. I faced a similar issue where my queries were taking too long due to the volume of data. By partitioning large tables, I was able to improve the query performance significantly. Partitioning helps by dividing your data into smaller, more manageable parts, making it faster to query and retrieve results. You can read more about how to implement partitioning in PostgreSQL and speed up your queries in this helpful guide on using partitions: How to Speed Up PostgreSQL Queries with Partitions.

[danolivo]

There are lots of caveats with partitions. I generally vote against it without strong reasons (usually substantial data volumes). At the same time, aggregate performance improvement is quite different optimisation that has a much more vast usability scope.

[An70ni]

А на операции distinct такие оптимизации распространяются?

[danolivo]

Ага, как раз сейчас почти уже закоммиченный патч в хакерсах лежит - см. Richard Guo's треды.

[An70ni]

Вообще, в универе у нас преподаватели учили расставлять ветки if в коде на основании знания статистики. То условие, которое случается чаще всего, выставлять раньше, чтобы меньше холостых срабатываний и переходов к следующим веткам. Не знаю используется ли такое в postgress, но можно было бы в операторе where добавлять. Приклеить к не уникальным индексам, может. Если значение встречается чаще других, или к нему обращений больше, то выставлять его для проверки раньше. Если там, конечно, какие-нибудь деревья не используются. Не силен в базах данных, так что не знаю.