Re: Set hint bits upon eviction from BufMgr

From: Jim Nasby <jim(at)nasby(dot)net>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Set hint bits upon eviction from BufMgr
Date: 2011-04-05 14:49:37
Message-ID: 103156DE-B474-43D1-B5C3-54A9FDCF19A4@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mar 28, 2011, at 9:48 AM, Merlin Moncure wrote:
> On Mon, Mar 28, 2011 at 9:29 AM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2011-04-05 14:59:30 Re: Recursive containment of composite types
Previous Message Tom Lane 2011-04-05 14:31:54 Re: time table for beta1