Интересно, а аггрегация SUM будет работать быстрее если на поле

будет навешан индекс?

От запроса же зависит. Но если только на поле, которое суммируется — он вряд ли будет использован вообще когда-либо (запросы вроде SELECT SUM(amount) FROM transaction; крайне редко используются, как мне кажется).

А есть ли какой-либо способ чтобы увеличивать скорость аггрегационных запросов? Чтобы SELECT SUM(amount) FROM transaction; быстрее отрабатывал?

Я же написал, что именно для такого запроса подобный индекс поможет. Встречный вопрос: зачем Вам именно такой запрос, а?

зависит от запроса и условия в запросе (все что идет после WHERE). Если условия нет - то запросу требуются все строи из таблицы - индекс тут не поможет. Если условие есть и нужна только какая-то небольшая часть строк которые будут браться именно по индексу - то индекс поможет.

> Если условия нет - то запросу требуются все строи из таблицы - индекс тут не поможет. Не обязательно. Я имел в виду Index-only scan, например.

index-only-scan поможет уменьшить на некоторый коэффициент время запроса. Зависит от ко-ва байт, которое занимает строка таблиицы. Почему-то мне кажется, что прирост будет не более, чем в 2 раза в среднем, поэтому если размер базы увеличится в 2 раза, то надо делать что-то ещё)

> что прирост будет не более, чем в 2 раза в среднем Мне тоже кажется, что в среднем где-то так. > то надо делать что-то ещё) Например, прекратить выполнять бессмысленные запросы. ;)

+

> Например, прекратить выполнять бессмысленные запросы. ;) Да, но это ведь бизнес требование. Что бы вы сделали в этом случае? взяли бы соотвествующую СУБД?

Нет, это не бизнес требование (в третий раз уже пишу)! Покажите мне, когда "бизнесу" нужно знать сумму поля в таблице без всяких фильтров. Обычно даже на SELECT COUNT(*) FROM any_table уже ругаются именно в этом плане, а уж у SELECT SUM(a_column) FROM any_table смысла ещё меньше, IMNSHO.

Разве index-only scan случится именно для такого запроса (если условие не задано)? https://t.me/pgsql/306470 - тут видно, что никакого index-only нет.

Надо ещё более искусственные тесты выполнять, ага — можно "доказать" вообще всё что угодно. ;( Естественно, что его там нет — для того, чтобы он был выгоден, размер таблицы должен существенно превышать размер индекса, в первую очередь. И так очень часто и будет для реальных таблиц.

Понял, спасибо.

Вы правда не верите, что так может быть?) Представим, что вы делаете контест систему (а-ля ACM или golf). Вам хочется видеть ко-во решений посланных по каждой задаче с разбивкой по каждому языку на страничке статистики. Ну тут как ни крути придётся достать все таски, сделать join со всеми решениями и после этого ещё сгруппировать.

Единственный способ ускорить на реляционных БД мне известный это делать материализованные виды. Ну или колоночная БД))

Ага

Я правда не верю, что Вы не умеете читать. ;) Ещё раз, никаких "разбивок" и т.п. — всё это делает указанный индекс (ON a_table(a_column)) абсолютно бесполезным. И, опять-таки, именно этот запрос ( SELECT SUM(a_column) FROM any_table) практически бесполезен, IMNSHO. У Вас есть что возразить на вышенаписанное?

Ещё выше про timescaledb писали. Я тут что-то нашёл, но ещё не прочитал https://docs.timescale.com/timescaledb/latest/how-to-guides/continuous-aggregates/create-a-continuous-aggregate/#using-with-no-data-when-creating-a-continuous-aggregate

Это тоже про агрегаты, только хитрые

Нету

Ну а я только это и имел в виду. Что касается реальных ситуаций — https://t.me/pgsql/306494

Ну, справедливости ради, есть один пример - многоэтапная обработка выборки во временной таблице. Вполне может понадобиться агрегировать без where. Пример не совсем честный, т.к. здесь временная таблица - инструмент оптимизации, да и выборка, по сути, уже отфильтрованная.

Я, кажется, никогда не видел, чтобы "обработка выборки во временной таблице" сводилась просто к SELECT SUM(field) FROM temp_table. Может, это и может быть промежуточным звеном какого-то процесса (т.е. с этой таблицей делают и что-то ещё)... но вот индексировать такое просто глупо, Вам не кажется?

Полностью согласен, поэтому и написал, что пример не честный.

почему глупо? там же может быть index-only scan

Потому что если единственной целью, с которой создавалась эта временная таблица, было сделать по ней SELECT SUM(field) FROM temp_table, то кто-то что-то делает не так, Вам не кажется? ;)

ну это да 😄