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
