we had some different idea here in the past: what if we had a procedure / method to allow people to save the list of
currentbuffers / cached blocks to be written to disk (sorted). we could then reload this "cache profile" on startup in
thebackground or people could load a certain cache content at runtime (maybe to test or whatever).
writing those block ids in sorted order would help us to avoid some random I/O on reload.
regards,
hans
On Mar 9, 2012, at 5:13 AM, Robert Haas wrote:
> It's been bugging me for a while now that we don't have a prewarming
> utility, for a couple of reasons, including:
>
> 1. Our customers look at me funny when I suggest that they use
> pg_relation_filepath() and /bin/dd for this purpose.
>
> 2. Sometimes when I'm benchmarking stuff, I want to get all the data
> cached in shared_buffers. This is surprisingly hard to do if the size
> of any relation involved is >=1/4 of shared buffers, because the
> BAS_BULKREAD stuff kicks in. You can do it by repeatedly seq-scanning
> the relation - eventually all the blocks trickle in - but it takes a
> long time, and that's annoying.
>
> So I wrote a prewarming utility. Patch is attached. You can prewarm
> either the OS cache or PostgreSQL's cache, and there are two options
> for prewarming the OS cache to meet different needs. By passing the
> correct arguments to the function, you can prewarm an entire relation
> or just the blocks you choose; prewarming of blocks from alternate
> relation forks is also supported, for completeness.
>
> Hope you like it.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
> <pg_prewarm_v1.patch>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
