Могли б помочь понять почему big query не восприимчив к изменению даты в условии where
Вот запрос , который обрабатывает 34 гигабайта Когда я пробую поменять в условии where 365 дней на 3 - на размер запроса это не влияет , хотя ему при этом нужно обработать в 20-30 раз меньше строк. Почему так ?
SELECT
Project,
Player,
DATE(DATE_SUB(created_at, INTERVAL 5 hour)) AS Date,
COUNT(PAY_ID) AS Pays
from transactions
WHERE
DATE(DATE_SUB(created_at, INTERVAL 5 hour)) > current_date()-365
GROUP BY Project, Player, Date
Ответы (1 шт):
Разница с тем что в советах в том, что там колонка напрямую сравнивается с каким-то константным выражением (пусть выражение и использует сложную функцию от CURRENT_DATE()).
WHERE data_date between DATE_SUB(CURRENT_DATE(), INTERVAL 14 day) ...
у вас же сложная функция применена к колонке, и потом сравнивается с каким-то выражением
DATE(DATE_SUB(created_at, INTERVAL 5 hour)) > current_date()-365
В их примере системе очень просто посчитать выражение и понять какие диапазоны data_date подходят, не проверяя каждого значения data_date. В этом и состоит экономия денег - быстро отсечь большинство партиций / кластеров, не смотря на конкретные значения (данные конечно должны быть PARTITIONED BY или CLUSTERED BY по этой колонке, или хотя бы по какой-нибудь коррелирующей с ней).
В вашем примере всё наоборот - какая-то сложная функция от created_at, как по ней оптимизатору понять какие диапазоны created_at подходят? Для этого оптимизатору надо было бы посчитать обратную функцию от вашей, что в общем случае невозможно, и он этим и не занимается кроме простейших случаев. Остается только проверять каждое значение, то есть full table scan.
Зато вы можете сделать это сами, записав условие в виде чего-то вроде
created_at > TIMESTAMP_ADD(TIMESTAMP(current_date() - 365), INTERVAL 5 HOUR)
(наверное я ошибся где-то в переписывании условия, но идея должна быть понятна)