w
ну оно возможно снизит стоимость группировки, но тут основная проблем именно в поиске нужных транзакций
provider_name, currency. Группировка ведь тоже по индексу работает, если я не ошибаюсьSize: a a a
2021 June 11
DK
Вряд ли сильно поможет, но индекс же нужен для
NB
COUNT(*) и COUN(1) - одно и то же . Не путать с SELECT *
DT
Зависит от БД, в постгресе вот влияет (хотя может починили уже) — https://blog.jooq.org/2019/09/19/whats-faster-count-or-count1/
DK
а, там вообще группировка миллисекунды занимает
DT
а можешь сделать explain analyze?
w
докинул в гист
w
уже прогрелось, достаточно быстро отработало
DT
А там в компании
147 много транзакций, да? Вообще count по умолчанию медленная штука, он после фильтрации и группировки всё равно пойдет перебирать все, что осталось.w
да, там 4млн записей в 147 компании
DT
Если точность не нужна, то можно посчитать примерное число через статистику (там хранятся распределения)
w
я думаю, что в цлом в этой задаче не важна точность, а важны пары, которые были использованы provider_name/currency,
и соответственно правильным решением тут пожалуй будет дистинкт, ну или глянуть через статистику.
Меня больше смущает, что делать дальше в такой ситуации. По этой компании кол-во транзакций будет расти, а любой запрос будет все медленнее и медленнее
и соответственно правильным решением тут пожалуй будет дистинкт, ну или глянуть через статистику.
Меня больше смущает, что делать дальше в такой ситуации. По этой компании кол-во транзакций будет расти, а любой запрос будет все медленнее и медленнее
P
я бы для такой большой таблицы держал периодические итоги, тогда обсчет сводится к получению итогов на начало периода и обсчета текущих транзакций
DT
Ещё опция если счётчиков мало — держать их в редисе и обновлять в фоне раз в период
w
спасибо, ребзя
AM
А что если это в M
И триггером обновлять данные?
aterialized View положить? И триггером обновлять данные?
CM
только не слишком часто, а то ООМ произойдёт 🌚
T
Кэшировать периодически в одну запись.