Re: Set hint bits upon eviction from BufMgr

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Set hint bits upon eviction from BufMgr
Дата
Msg-id BANLkTim5BALObu2VQKsGjRAceNLzi4pEvw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Set hint bits upon eviction from BufMgr  (Jim Nasby <jim@nasby.net>)
Список pgsql-hackers
On Tue, Apr 5, 2011 at 9:49 AM, Jim Nasby <jim@nasby.net> wrote:
> On Mar 28, 2011, at 9:48 AM, Merlin Moncure wrote:
>> On Mon, Mar 28, 2011 at 9:29 AM, Kevin Grittner
>> <Kevin.Grittner@wicourts.gov> wrote:
>>> Tom Lane <tgl@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
furtherinvestigation and want to make sure they don't get lost. 

No, they don't -- and I plan to work on this independently.

The performance tradeoffs here are much more complicated and will
require extensive benchmarking to analyze.  A process local clog
cache, if it can be made to work (and that's be no means certain) is
going to affect how this is put together.  In particular, i'd be even
more disinclined to adjust scan priorty or do anything fancy like that
-- and more amenable to checking every tuple.   I'm particularly
interested in setting the PD_ALL_VISIBLE bit at eviction time if it's
available to be set and the page is already dirty.

merlin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Transforming IN (...) to ORs, volatility
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: WIP: Allow SQL-language functions to reference parameters by parameter name