Re: pg_prewarm
Peter Eisentraut <peter_e@gmx.net>
From: Peter Eisentraut <peter_e@gmx.net>
To: cedric@2ndquadrant.com
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org, Stefan Keller <sfkeller@gmail.com>
Date: 2012-06-20T19:53:43Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
pgstattuple: Use a BufferAccessStrategy object to avoid cache-trashing.
- 2e46bf671145 9.2.0 cited
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.)