Представлен (http://permalink.gmane.org/gmane.comp.db.postgresql.announce...) первый стабильный релиз проекта PgFincore 1.0 (http://villemain.org/projects/pgfincore), в рамках которого подготовлен набор инструментов (https://github.com/klando/pgfincore#readme) для анализа использования и управления дисковыми кэшами в PostgreSQL.
Из полезных функций PgFincore можно отметить возможность сохранения состояния дисковых кэшей с их последующим восстановлением, например, для ускорения "прогрева" сервера после перезагрузки или при поднятии запасного сервера на другой машине. Сохранив прокэшированные в памяти дисковые блоки таблиц и индексов перед перезагрузкой сервера и восстановив их после, можно повысить производительность начального этапа работы СУБД за счет минимизации ввода/вывода при выполнении штатных задач.
URL: http://permalink.gmane.org/gmane.comp.db.postgresql.announce...
Новость: http://www.opennet.me/opennews/art.shtml?num=31342
На кой ляд это? Какого размера кэш буферов БД может быть в постгресе, что его надо сохранять на диск и загружать с диска? Что, просто предвыборки средствами ФС недостаточно?
Вероятно, кто-то нашел зачем.
Это как загружаться из хибернейта. Всё сразу же инициализировано и готово обслуживать.
Мда? А какому недоумку придет в голову рестартовать сервер БД размером 6 петабайт, к примеру? Просто посмотреть, как быстро он запустится? Как виндузятники меряются фаллосами, чья винда быстрее стартанет до Ctrl-Alt-Del?
> Мда? А какому недоумку придет в голову рестартовать сервер БД размером 6
> петабайт, к примеру? Просто посмотреть, как быстро он запустится? Как виндузятники
> меряются фаллосами, чья винда быстрее стартанет до Ctrl-Alt-Del?И, кстати, скажите-ка мне, дураку, как, черт побери, прокешировать базу в 6 петабайт, чтобы по-шустрому ее загрузить в память? Ась? Не слышу!!!
кэшировать надо не при старте, а во время работы.
а зачем кешировать всю базу, они кешируют рабочий набор, которы
А как раз это пытается сделать 90% недоум^Wадминов и программеров.
На серьёзной машине, скажем, с четвертью ТБ памяти, в той самой памяти может быть немало часто-используемых данных, на выборку которых было потрачено немало ресурсов. Почему бы их не запомнить, а потом не загрузить во время поднятия сервера?
Да, давай-ка найдем в кэше часто используемые ad-hoc запросы для DWH серьезной машины. Серьезная машина для чего-то кроме DWH используется? Имея четверть терабайта памяти, как-то глупо туда засунуть OLTPшку на 100 Гб, правда?
> На серьёзной машине, скажем, с четвертью ТБ памяти, в той самой памяти
> может быть немало часто-используемых данных, на выборку которых было потрачено немало
> ресурсов. Почему бы их не запомнить, а потом не загрузить во
> время поднятия сервера?Кстати, в постгресе когда-то появились summaries или materialized views? Давно ли?