Re: pg_prewarm

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: pg_prewarm
Дата
Msg-id 1340222023.26286.54.camel@vanquo.pezone.net
обсуждение исходный текст
Ответ на Re: pg_prewarm  (Cédric Villemain <cedric@2ndquadrant.com>)
Ответы Re: pg_prewarm  (Robert Haas <robertmhaas@gmail.com>)
Re: pg_prewarm  (Cédric Villemain <cedric@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Event Triggers reduced, v1
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pgbench--new transaction type