On Mar 28, 2011, at 9:48 AM, Merlin Moncure wrote: > On Mon, Mar 28, 2011 at 9:29 AM, Kevin Grittner > <kevin.gritt...@wicourts.gov> wrote: >> Tom Lane <t...@sss.pgh.pa.us> wrote: >> >>> The major problem with all of this is that the bgwriter has no >>> idea which buffers contain heap pages. And I'm not convinced it's >>> a good idea to try to let it know that. If we get to the point >>> where bgwriter is trying to do catalog accesses, we are in for a >>> world of pain. (Can you say "modularity violation"? How about >>> "deadlock"?) >> >> How about having a BackgroundPrepareForWriteFunction variable >> associated with each page the bgwriter might see, which would be a >> pointer to a function to call (if the variable is not NULL) before >> writing? The bgwriter would still have no idea what kind of page it >> was or what the function did.... > > Well, that is much cleaner from abstraction point of view but you lose > the ability to adjust scan priority before flushing out the page...I'm > assuming by the time this function is called, you've already made the > decision to write it out. (maybe priority is necessary and maybe it > isn't, but I don't like losing the ability to tune at that level). > > You could though put a priority inspection facility behind a similar > abstraction fence (BackgroundGetWritePriority) though. Maybe that's > more trouble than it's worth though.
Merlin, does your new work on CLOG caching negate anything in this thread? I think there's some ideas here worth further investigation and want to make sure they don't get lost. -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
