Здравствуйте, gandjustas, Вы писали:

EP>>>>В buffer pool ведь сидят страницы, в которых находятся целые строки таблиц, так? Тогда:
EP>>>>1. Закэшированный результат запроса скорей всего будет занимать меньше памяти чем "эквивалентный" набор страниц для повторного запроса, так как в нём будет меньше столбцов и строк — только самое необходимое. А следовательно будет больше свободной памяти, которую можно использовать под другие страницы, или другие кэши запросов.
G>>>Интересно как ты это посчитал.
EP>>Вариант 1. Запрос с агрегированием и группировкой, да ещё и не по всем столбцам — результат очевидно меньше чем исходные данные.
G>Да, только в случае агрегации актуально, но это если таблица не используется в других запросах.

Как видишь, "не всё так однозначно" (c) — используя кэш всё-таки можно увеличить "свободную память"

EP>>Вариант 2. Запрос с фильтрацией, с выводом всех столбцов. Без кэша результата, даже если загружены в память только минимально необходимые страницы, то они всё равно будут содержать неиспользуемые строки, помимо этого в памяти будут сидеть страницы соответствующего индекса.
EP>>Вариант 3. Запрос выводит все строки*столбцы, но в определённом порядке. В этом случае память также будет расходоваться под индекс, а в случае готового результата — нет, не говоря уже о том что линейный обход памяти на порядок (а бывает и на порядки) эффективней случайного.
G>Ты точно знаешь как базы работают? Про покрывающие индексы не слышал?

И чем они помогут в случае динамических фильтров и динамических предикатов?

EP>>Хотя можно представить случаи где и автоматический кэш будет эффективен
G>Представить вообще можно что угодно, а вот на практике встретить не всегда.

Кто-то встретит, кто-то нет — для этого есть настройки.

EP>>>>2. Даже если все необходимые страницы в памяти, то "эквивалетная" закэшированному запросу операция может занять намного больше времени — так как требуется обработать больше данных из random'ных участков памяти.
G>>>Тытоже не понимаешь как базы работают?
EP>>А ты перестал пить коньяк по утрам?
G>Ответить нечего?

Я уже писал ранее что с СУБД вообще не приходится работать. Это, тем не менее, не освобождает оппонента от необходимости аргументировать свою позицию

G>>>Когда данные уж в ОП, то там различия минимальные, доли миллисекунд.
EP>>Элементарный пример — есть таблица в 30 гигабайт, для неё нужно сделать агрегирование с результатом в одну строчку. Угадай что будет быстрее — закэшированный результат или полное вычисление?
G>Индексированное представление, а кэш не нужен.

Для динамических запросов, с динамическими формулами?

EP>>Пример конечно экстремальный, но поинт простой — готовый результат может быть в разы, а то и на порядки быстрее чем сырые данные. Причём не теряет актуальность даже в если до DB существенное latency — например в том случае если запросов много.
G>Походу ты действительно не знаешь как работают базы данных.

Аргументов как всегда не будет?

G>Не продолжай пожалуйста.

Давай, удачи, слив засчитан