pg_prewarm - Mailing list pgsql-hackers

From Robert Haas
Subject pg_prewarm
Date
Msg-id CA+TgmobRrRxCO+t6gcQrw_dJw+Uf9ZEdwf9beJnu+RB5TEBjEw@mail.gmail.com
Whole thread Raw
Responses Re: pg_prewarm  (Jaime Casanova <jaime@2ndquadrant.com>)
Re: pg_prewarm  (Joshua Drake <jd@commandprompt.com>)
Re: pg_prewarm  (Devrim GÜNDÜZ <devrim@gunduz.org>)
Re: pg_prewarm  (Fujii Masao <masao.fujii@gmail.com>)
Re: pg_prewarm  (Hans-Jürgen Schönig <postgres@cybertec.at>)
Re: pg_prewarm  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: RFC: Making TRUNCATE more "MVCC-safe"
Next
From: Jaime Casanova
Date:
Subject: Re: pg_prewarm