Я заметил, что даже самый простой «SELECT MAX (TIMESTAMP) FROM MYVIEW» несколько медленный (занимает минуты) в моей среде, и обнаружил, что он выполняет TableScan размером 100 + ГБ в микроперегородках 80K.
Мои ожидания было ли это до конечной sh в миллисекундах с использованием метаданных MIN / MAX / COUNT в каждом микроперегородке. Фактически, я вижу, как Снежинка завершает работу за миллисекунды, используя метаданные для почти одинакового поиска значения MIN / MAX в следующей статье:
http://cloudsqale.com/2019/05/03/performance-of-min-max-functions-metadata-operations-and-partition-pruning-in-snowflake/
Есть ли ограничение в том, как Snowflake решает использовать метаданные? Может ли это быть потому, что я запрашиваю представление, вместо того, чтобы обращаться к таблице напрямую?
=== Добавлено для ясности ===
Спасибо за ответ! Относительно того, как определяется представление, кажется, что он добавляет предложение WHERE для дополнительной фильтрации с ключом кластера. Поэтому я считаю, что все еще должно быть возможно полностью использовать метаданные микроперегородок. Но, как сообщалось, TableScan выполняется в выводе профилировщика.
Я немного обеспокоен вашим комментарием к SecureView. Представление, которое я запрашиваю, действительно является БЕЗОПАСНЫМ. Это влияет на то, как оптимизатор обрабатывает мой запрос? Может ли это быть причиной того, почему TableScan сделано?