Аналитик считает воронку: сначала фильтрует события в CTE events_filtered, затем ссылается на неё 3 раза в разных JOIN. В PostgreSQL запрос стал медленным. Что вероятная причина и решение?
SQLhardsenior
Проверяет владение SQL: выборки, агрегации, JOIN-ы и оконные функции.
CTEоптимизацияматериализация
Варианты ответа
CTE в PostgreSQL всегда пересчитывается заново при каждой ссылке, поэтому 3 ссылки означают 3 полных прогона фильтрации; заменить CTE на временную таблицу с индексом и ссылаться на неё
CTE нельзя джойнить более двух раз в одном запросе, третья ссылка вызывает полный Seq Scan базовой таблицы; ограничиться двумя ссылками, а третий JOIN вынести в отдельный запрос
CTE по определению игнорирует индексы базовых таблиц при материализации; переписать логику воронки через оконные функции ROW_NUMBER/LAG без промежуточного CTE
До PG12 CTE был optimization fence и материализовался один раз, но повторные ссылки читают материализованный набор без пушдауна предикатов; вынести в подзапрос или добавить условия внутрь CTE
Как разобрать этот вопрос на собеседовании
Начни с разбора схемы: какие таблицы и ключи участвуют, где могут быть NULL и дубли строк. Затем реши, что важнее — JOIN, агрегация с GROUP BY/HAVING, оконная функция или подзапрос. На собеседовании ценят не только правильный результат, но и умение проговорить план запроса и крайние случаи (пустые группы, деление на ноль, фан-аут при JOIN).
Это вопрос продвинутого уровня — на собеседовании по нему обычно идут уточняющие follow-up вопросы, поэтому держи в голове крайние случаи и альтернативные решения.
Тема вопроса — «SQL». Чтобы подготовиться к похожим задачам, отрабатывай их на практике: sql-тренажёр помогает довести навык до автоматизма, а раздел вопросов — увидеть формулировки, которые реально встречаются на интервью аналитика данных.
Разбор ответа
Подробный разбор с объяснением «почему правильный ответ верный» и почему остальные неверны — после регистрации.
3000+ вопросов с разбором, quiz-режим с проверкой, AI-собес и подготовка к интервью аналитика.