Alvaro Herrera wrote:
> As for gain, I have heard of test setups requiring hours of runtime in
> order to prime the buffer cache.
>
And production ones too. I have multiple customers where a server
restart is almost a planned multi-hour downtime. The system may be back
up, but for a couple of hours performance is so terrible it's barely
usable. You can watch the MB/s ramp up as the more random data fills in
over time; getting that taken care of in a larger block more amenable to
elevator sorting would be a huge help.
I never bothered with this particular idea though because shared_buffers
is only a portion of the important data. Cedric's pgfincore code digs
into the OS cache, too, which can then save enough to be really useful
here. And that's already got a snapshot/restore feature. The slides at
http://www.pgcon.org/2010/schedule/events/261.en.html have a useful into
to that, pages 30 through 34 are the neat ones. That provides some
other neat APIs for preloading popular data into cache too. I'd rather
work on getting something like that into core, rather than adding
something that only is targeting just shared_buffers.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
