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

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

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

EP>И чем они помогут в случае динамических фильтров и динамических предикатов?
В случае если пользователь может "накликать" любой запрос и кэш не поможет. Hit ratio будет низким.
Но в реальном приложении "произвольный" запрос к таблицам на миллионы строк можно встретить очень нечасто.

EP>Я уже писал ранее что с СУБД вообще не приходится работать. Это, тем не менее, не освобождает оппонента от необходимости аргументировать свою позицию
Тогда специально для тебя еще раз объясняю. Задача СУБД — оптимизировать чтение с диска. Чтение одной "страницы" занимает 5-10 мсек, сколько там операций в памяти можно сделать за это время?

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

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

G>>Не продолжай пожалуйста.
EP>Давай, удачи, слив засчитан
Тебе, конечно, никто не мешает считать себя умнее, но умнее от этого ты не станешь. Увы.