SELECT [DEFER] * FROM…
Я тут подумал, что было бы очень круто как помечать запросы флагом, который бы говорил СУБД «если такой же запрос уже выполняется, то меня устроят его результаты, новый запускать не надо». Было бы очень полезно для запросов, в которых не нужна оперативность и которые заказываются большим числом пользователей.
Конечно такое можно кешировать со стороны приложения (что у нас и делается в продукте), но встают вопросы инвалидации кеша, предотвращения одновременного выполнения одного и того же запроса несколько раз, если в кеше что-то не нашлось, обработки ошибок от базы и так далее.
Со стороны СУБД было бы интереснее такое увидеть.
Materialized view.
Поддерживаю, отличная идея!
Комментарий для PastorGL:
Нет.
Да, materialized view требуется вручную обновлять. По крайней мере в Postgres. Инвалидации кеша и другие проблемы остаются.
SELECT DEFER — интересный предложение. Но было бы ещё лучше, если бы база данных умела эффективно реагировать на произвольные изменения во входных данных запроса. Предположим, есть периодический запрос SELECT SUM(amount) FROM transfer. В таблице transfer сто миллионов строк. За один час в таблице изменяется/добавляется десять тысяч строк. Свежий результат запроса этого запроса современные БД будут вычислять за время порядка размера всей таблицы. Но очевидно, что в БД есть вся информация, чтобы делать это за время порядка скорости изменений в таблице. Было бы круто, если БД научились так делать. И не только в тривиальных случаях вроде суммы, а *для произвольных запросов*.
Исследование на эту тему: https://github.com/frankmcsherry/differential-dataflow
Комментарий для Алексей Шамрин:
SUM(amount) умеют хорошо колоночные СУБД. Кроме того, если в Оракле навесить пересчёт MV (быстрым методом, то есть с логами по таблице) на триггер — то вот оно решение. В Постгресе, увы «быстрых» MV не вовсе.
Комментарий для Евгения Степанищева:
Не очень понятно, что значит «быстрый метод». Можно чуть подробней?
Комментарий для Алексей Шамрин:
Ну он так и называется «быстрый метод» (fast method or fast refresh), можно погуглить. Это не полный пересчёт MV с нуля, а добавление данными (на основе логов по полям, задействованным в запросе). У метода масса ограничений, которые тоже гуглятся. Я на этих вьюхах счётчики документов делал в нашем СЭДе.
Oracle: result cache
Комментарий для xyz:
Я не про кеш, прочитайте внимательно, пожалуйста.