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

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

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

EP>Вариант 1. Запрос с агрегированием и группировкой, да ещё и не по всем столбцам — результат очевидно меньше чем исходные данные.
Да, только в случае агрегации актуально, но это если таблица не используется в других запросах.

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

G>>Даже если в программе банальный CRUDL, то к каждой таблице идет минимум два запроса — на получение списка и на чтение одной строки по ключу. То есть в кеше будет занимать БОЛЬШЕ данных чем buffer pool. В реальном приложении, с джоинами будет еще больше данных в кеше. А если список достаточно большой и запросы равновероятны, то от кеша вообще толку нет, так как hit ratio будет слишком низкий.

EP>А я не говорил что нужно кэшировать все запросы.
А вот a_alex_public_ утверждал что автокеш в базе — хорошее решение.

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

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

G>>Когда данные уж в ОП, то там различия минимальные, доли миллисекунд.

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

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