Re: pg_prewarm - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: pg_prewarm
Date
Msg-id 1340222023.26286.54.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: pg_prewarm  (Cédric Villemain <cedric@2ndquadrant.com>)
Responses Re: pg_prewarm
Re: pg_prewarm
List pgsql-hackers
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'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.

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.)




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Event Triggers reduced, v1
Next
From: Robert Haas
Date:
Subject: Re: pgbench--new transaction type