SELECT [DEFER] * FROM…

Я тут подумал, что было бы очень круто как помечать запросы флагом, который бы говорил СУБД «если такой же запрос уже выполняется, то меня устроят его результаты, новый запускать не надо». Было бы очень полезно для запросов, в которых не нужна оперативность и которые заказываются большим числом пользователей.

Конечно такое можно кешировать со стороны приложения (что у нас и делается в продукте), но встают вопросы инвалидации кеша, предотвращения одновременного выполнения одного и того же запроса несколько раз, если в кеше что-то не нашлось, обработки ошибок от базы и так далее.

Со стороны СУБД было бы интереснее такое увидеть.
1 августа 2017 17:18

PastorGL (инкогнито)
1 августа 2017, 19:29

Materialized view.

lazarevmax (инкогнито)
1 августа 2017, 19:46

Поддерживаю, отличная идея!

bolknote.ru (bolknote.ru)
2 августа 2017, 06:51, ответ предназначен PastorGL

Materialized view.
Нет.

Алексей Шамрин (инкогнито)
2 августа 2017, 15:55

Да, materialized view требуется вручную обновлять. По крайней мере в Postgres. Инвалидации кеша и другие проблемы остаются.

SELECT DEFER - интересный предложение. Но было бы ещё лучше, если бы база данных умела эффективно реагировать на произвольные изменения во входных данных запроса. Предположим, есть периодический запрос SELECT SUM(amount) FROM transfer. В таблице transfer сто миллионов строк. За один час в таблице изменяется/добавляется десять тысяч строк. Свежий результат запроса этого запроса современные БД будут вычислять за время порядка размера всей таблицы. Но очевидно, что в БД есть вся информация, чтобы делать это за время порядка скорости изменений в таблице. Было бы круто, если БД научились так делать. И не только в тривиальных случаях вроде суммы, а *для произвольных запросов*.

Исследование на эту тему: https://github.com/frankmcsherry/differential-dataflow

bolknote.ru (bolknote.ru)
2 августа 2017, 17:14, ответ предназначен Алексей Шамрин

SUM(amount) умеют хорошо колоночные СУБД. Кроме того, если в Оракле навесить пересчёт MV (быстрым методом, то есть с логами по таблице) на триггер — то вот оно решение. В Постгресе, увы «быстрых» MV не вовсе.

Алексей Шамрин (инкогнито)
2 августа 2017, 17:50, ответ предназначен bolknote.ru:

если в Оракле навесить пересчёт MV (быстрым методом, то есть с логами по таблице) на триггер
Не очень понятно, что значит "быстрый метод". Можно чуть подробней?

bolknote.ru (bolknote.ru)
3 августа 2017, 08:29, ответ предназначен Алексей Шамрин

Ну он так и называется «быстрый метод» (fast method or fast refresh), можно погуглить. Это не полный пересчёт MV с нуля, а добавление данными (на основе логов по полям, задействованным в запросе). У метода масса ограничений, которые тоже гуглятся. Я на этих вьюхах счётчики документов делал в нашем СЭДе.

xyz (инкогнито)
11 августа 2017, 22:14

Oracle: result cache

bolknote.ru (bolknote.ru)
12 августа 2017, 19:45, ответ предназначен xyz

Я не про кеш, прочитайте внимательно, пожалуйста.

Ваше имя или адрес блога (можно OpenID):

Текст вашего комментария, не HTML:

Кому бы вы хотели ответить (или кликните на его аватару)