Re: pg_prewarm

Le mercredi 20 juin 2012 21:53:43, Peter Eisentraut a écrit :
> On tis, 2012-04-10 at 13:29 +0200, Cédric Villemain wrote:
> > I have no problem deprecating overlapping features from pgfincore as
> > soon as I can do a «depend:pg_prewarm[os_warm]» :) ...It would have
> > been better to split pgfincore analyze and warming parts times
> > ago, anyway.
>
> So pg_prewarm is now pending in the commitfest, so let's see what the
> situation is.

I have refused to propose pgfincore so far because BSD didn't supported
POSIX_FADVISE (but already supported mincore(2)).
Now, things change and pgfincore should work on linux, bsd, hp, ... (but not
on windows)
I'll be happy to propose it if people want.

> I'm worried about the overlap with pgfincore. It's pretty well
> established in this space, and has about 73% feature overlap with
> pg_prewarm, while having more features all together. So it would seem
> to me that it would be better to add whatever is missing to pgfincore
> instead. Or split pgfincore, as suggested above, but that would upset
> existing users. But adding severely overlapping stuff for no technical
> reasons (or there any?) doesn't sound like a good idea.

And I am also worried with the overlap.

> Also, Robert has accurately described this as "mechanism, not policy".
> That's fine, that's what all of our stuff is. Replication and most of
> postgresql.conf suffers from that. Eventually someone will want to
> create a way to save and restore various caches across server restarts,
> as discussed before. Would that mean there will be a third way to do
> all this, or could we at least align things a bit so that such a
> facility could use most of the proposed prewarming stuff? (Patches for
> the cache restoring exist, so it should be possible to predict this a
> little bit.)

It makes some time I have a look at the postgresql source code about
readBuffer and friends. AFAIR pgfincore needed some access to file decsriptor
which were not possible with PostgreSQL core functions.

I can have a look as this is near the stuff I'll work on next (posix_fadvice
random/sequential/normal applyed directly by PostgreSQL, instead of relying
on hacks around read-the-first-block to start readahead).

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation