Согласен, в DWH, много-командных базах и при миграциях view, как контракт - интерфейса незаменимы. В статье это в итогах: "переиспользуемый фильтр и стабильный контракт чтения", "разделение прав", "мягкая миграция", "legacy, который проще обернуть". Мой кейс это OLTP highload, там агрегаты, часто дешевле выносить в сводные таблицы с инкрементальным обновлением.
Текст написан мною вручную. Все замеры берутся со стенда github.com/alex-frolov/mysql-postgresql-view-test, и запускается одной командой. Если есть конкретные технические вопросы по цифрам или планам - с удовольствием разберу.
Функциональный индекс на ((created_at)::date) это правильный фикс. В статье показано, почему без него планировщик не может использовать индекс (merchant_id, created_at), view выставляет наружу day как выражение, а не колонку. Функциональный индекс решает, но требует DDL и понимания, что view «молча» ломает саргабельность, именно этот момент показателен, без вникания и проверок можно попасть на ровном месте.
Согласен, 4 МБ это дефолт, специально оставил "как из коробки", чтобы показать поведение по умолчанию. Обычно work_mem поднимают, тогда каскад не скидывается на диск и PostgreSQL выигрывает у прямого запроса за счёт параллелизма. В статье это в разделе "Каскад": поменяйте work_mem, и цифры поедут.
Стенд открыт на github.com/alex-frolov/mysql-postgresql-view-test, там docker compose up && make bench. CLICK-подобные ворклоады прогоняются так же, дописываешь свой SQL в bench/queries.sql и запускаешь. Если соберёшь интересные цифры, присылай PR, с удовольствием приму, посмотрю. Можно и здесь обсудить.
Информация
В рейтинге
103-й
Откуда
Россия
Зарегистрирован
Активность
Специализация
Бэкенд разработчик, Архитектор программного обеспечения
Точно. В статье это "переиспользуемый фильтр и стабильный контракт чтения" + «"legacy, который проще обернуть". Для OLAP/DWH — основной паттерн.
Классический паттерн blue-green через view. Работает отлично для миграций схемы.
Согласен, в DWH, много-командных базах и при миграциях view, как контракт - интерфейса незаменимы. В статье это в итогах: "переиспользуемый фильтр и стабильный контракт чтения", "разделение прав", "мягкая миграция", "legacy, который проще обернуть". Мой кейс это OLTP highload, там агрегаты, часто дешевле выносить в сводные таблицы с инкрементальным обновлением.
Текст написан мною вручную. Все замеры берутся со стенда github.com/alex-frolov/mysql-postgresql-view-test, и запускается одной командой. Если есть конкретные технические вопросы по цифрам или планам - с удовольствием разберу.
Функциональный индекс на
((created_at)::date)это правильный фикс. В статье показано, почему без него планировщик не может использовать индекс(merchant_id, created_at), view выставляет наружу day как выражение, а не колонку. Функциональный индекс решает, но требует DDL и понимания, что view «молча» ломает саргабельность, именно этот момент показателен, без вникания и проверок можно попасть на ровном месте.Согласен, 4 МБ это дефолт, специально оставил "как из коробки", чтобы показать поведение по умолчанию. Обычно work_mem поднимают, тогда каскад не скидывается на диск и PostgreSQL выигрывает у прямого запроса за счёт параллелизма. В статье это в разделе "Каскад": поменяйте work_mem, и цифры поедут.
Стенд открыт на
github.com/alex-frolov/mysql-postgresql-view-test, тамdocker compose up && make bench. CLICK-подобные ворклоады прогоняются так же, дописываешь свой SQL вbench/queries.sqlи запускаешь. Если соберёшь интересные цифры, присылай PR, с удовольствием приму, посмотрю. Можно и здесь обсудить.