Re: pg_rewarm status - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: pg_rewarm status
Date
Msg-id CAMkU=1xOWa5iHQ0hP+5xTDVm3=75RXNB1UG=Qe_oYJF5hXkZGg@mail.gmail.com
Whole thread Raw
In response to Re: pg_rewarm status  (Jim Nasby <jim@nasby.net>)
Responses Re: pg_rewarm status
List pgsql-hackers
On Tue, Dec 17, 2013 at 8:02 AM, Jim Nasby <jim@nasby.net> wrote:
On 12/17/13, 8:34 AM, Robert Haas wrote:
On Tue, Dec 17, 2013 at 12:09 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
I have used pg_prewarm during some of work related to Buffer Management and
other performance related work. It is quite useful utility.
+1 for reviving this patch for 9.4

Any other votes?

We've had to manually code something that runs EXPLAIN ANALYZE SELECT * from a bunch of tables to warm our caches after a restart, but there's numerous flaws to that approach obviously.

Unfortunately, what we really need to warm isn't the PG buffers, it's the FS cache, which I suspect this won't help. But I still see where just pg_buffers would be useful for a lot of folks, so +1.

Since it doesn't use directIO, you can't warm the PG buffers without also warming FS cache as a side effect.  That is why I like 'buffer' as the default--if the data fits in shared_buffers, it warm those, otherwise it at least warms the FS.  If you want to only warm the FS cache, you can use either the 'prefetch' or 'read' modes instead.

 Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: patch: make_timestamp function
Next
From: Stephen Frost
Date:
Subject: Re: Extension Templates S03E11