Модификатор allowLargeResults включен, и я также пробовал использовать интерактивный и пакетный запрос. Есть 70M записей в таблице search_results, 10M записей в поиск и около (просто) 900 в купить стол. А также WHERE значительно сокращает количество строк.Google Bigquery говорит «Ответ слишком большой, чтобы вернуться» с простым выбором
SELECT
s.flyFrom, s.to, s.typeFlight, r.price, b.price, b.affily
FROM [sptest.buy] AS b
INNER JOIN [sptest.search_results] AS r
ON b.booking_token=r.booking_token
INNER JOIN [sptest.searches] AS s
ON s.searchid=r.searchid
WHERE
DATE(r.saved_at) >= DATE('2015-06-23 00:00:00') AND
DATE(s.saved_at) >= DATE('2015-06-23 00:00:00')
LIMIT 10
Возможно, проблема связана с большими соединительными клавишами? Ключ booking_token имеет размер 50-600 символов.
Спасибо! Он работает: «Истеклось 8.3 с, обработано 61,8 ГБ». Я не знал, что эти подзапросы разрешены в Bigquery. –
Конструкция JOIN EACH мне интересна. Я понимаю, что он используется, чтобы намекнуть на оптимизатор запросов, с которым мы имеем дело с большими таблицами. Похоже, что оптимизатор должен уже знать, насколько велики таблицы, и обрабатывать его внутренне? –
Да, вы правы, это подсказка, и в простых случаях оптимизатор должен знать размеры, но когда соединение происходит по подзапросам - это может ошибиться в оценке мощности. Хорошей новостью является то, что мы (медленно) развертываем более динамический алгоритм объединения, который заставит КАЖДЫЙ намек не понадобиться, но тем временем он может помочь. –