VGreyСуть вопроса в следующем:
В MySQL есть кеш запросов ( query_cache ). На веб-приложениях он довольно эфективен, процент попадания довольно высок.
Как с этим обстоят дела в Postgres?

PostgreSQL-хакеры обоснованно считают подобное злом. По их мнению, база данных не должна заниматься кешированием результатов запросов, это прерогатива приложения. Поэтому, как правильно замечено выше -- ставьте memcache. pgmemcache многие хакеры, кстати, тоже не очень жалуют по идеологическим соображениям -- они так бьются за транзакционную чистоту происходящего в базе, что держать под боком кеш, которому до транзакций нет дела совсем не подходит.

Andrey Daeron iz VGreyСуть вопроса в следующем:
В MySQL есть кеш запросов ( query_cache ). На веб-приложениях он довольно эфективен, процент попадания довольно высок.
Как с этим обстоят дела в Postgres?

PostgreSQL-хакеры обоснованно считают подобное злом. По их мнению, база данных не должна заниматься кешированием результатов запросов, это прерогатива приложения. Поэтому, как правильно замечено выше -- ставьте memcache. pgmemcache многие хакеры, кстати, тоже не очень жалуют по идеологическим соображениям -- они так бьются за транзакционную чистоту происходящего в базе, что держать под боком кеш, которому до транзакций нет дела совсем не подходит.
Да они не только за транзакционную чистоту бьются, как посмотриш почему некоторые идеи "в отказник" - понимаешь, что они, судя по всему, "хреновы математики" и борятся еще и за математически безупречную идеологичски-алгоритмическую чистоту. Из серии если это будет работать не всегда, то мы это делать не будем. Например (из растроившего) - мультитабличные индексы (да-да те самые которые решают проблему форейнов при партиционированиии таблиц).

Да, иногда и хорошие идеи отвергаются, согласен. Но если смотреть на проблему шире, то такая консервативность сохраняет всем известную стабильность и надежность PostgreSQL, в ущерб, конечно, некоторым новым идеям и фишкам. Но это уже совсем другая дискуссия.

assa Andrey Daeron Кто сам без греха пусть и кидает камни
Из тех СУБД с которыми я работал - вполне стабильная и предсказуемая. Баги скорее иногда встречаются, примерно как и в Оракле, и зачастую обходятся.не имею ничего против.
просто достают рекламные лозунги примазавшихся. могут отрабатывать свое рекламное "блаблабла" где-нито в другом месте.

assa, это вы все о чем? Причем здесь рекламные лозунги?

Моя мысль была проста, как 2 копейки: если разработчики любой СУБД принимают все новые идеи и веяния, бросаясь их реализовывать, получается нестабильный продукт. Если отказываются от всего нового -- то можно сделать идеально стабильную систему, но она мало кому будет нужна по причине отставания от жизни. В реальности всегда имеет место быть некоторый компромисс. Насколько я могу судить, в PostgreSQL эта грань смещена в сторону стабильности -- поэтому-то многие и жалуются (справедливо) на то, что разработчики зачастую отклоняют новые идеи или кладут их в долгий ящик. Вот и вся реклама.

PostreSQL начинающийУмеренный консерватизм вообще - отличная политика.

именно это я и хотел сказать. но слово "умеренный" все понимают по-разному, поэтому иногда и anticipated features отклоняются из-за частного мнения основных разработчиков. с этим, правда, тоже особо не поспоришь, т.к. количество рабочего времени у них, очевидно, ограничено.