Re: ARC buffer strategy committed - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: ARC buffer strategy committed
Date
Msg-id 3FB3AC3B.8010401@Yahoo.com
Whole thread Raw
In response to ARC buffer strategy committed  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>> Yeah, adding a buffer multiple times to the list of unused buffers 
>> ensures that it later on gets used for multiple contents simultaneously. 
> 
> Hm.  Looking at the patch last night, I was wondering why you had
> removed all the guard logic from BufTableInsert and BufTableDelete.
> Was that indeed a bad idea?  In particular, the removal of this bit
> from BufTableDelete

I had to, because that BufTable does not contain references to page 
buffers any more, it contains references to cache directory entries 
(CDB), which can reference a buffer (T1 and T2 CDBs) or can just 
remember the block-tag of a page that once was in memory (B1 and B2 
CDBs). When a CDB gets removed from that hash-table, its page is long 
gone from the memory. As a matter of fact since it is a part of the 
replacement strategy, it should reside in freelist.c ... and freelist.c 
should be renamed to buf_strategy.c or so.

Also, the whole freelist thing was totally misnamed. GetFreeBuffer() did 
not return a free buffer, but an unpinned one that might be free, used 
or even dirty. So the old "freelist" simply contained all unpinned 
buffers. PinBuffer() removed it from there when it changed refcount from 
zero, and UnpinBuffer() added it back when the refcount dropped to zero.

This all has changed. The freelist in ARC really contains clean and 
unused buffers. I think I should write up a README.freelist explaining 
the new bufmgr<->strategy interface and how the algorithm works.


Jan

> 
>     /*
>      * Clear the buffer's tag.  This doesn't matter for the hash table,
>      * since the buffer is already removed from it, but it ensures that
>      * sequential searches through the buffer table won't think the buffer
>      * is still valid for its old page.
>      */
>     buf->tag.rnode.relNode = InvalidOid;
>     buf->tag.rnode.tblNode = InvalidOid;
> 
> worries me quite a lot, because I *know* that was necessary before.
> Have you really changed the search algorithms to the point where it's not?
> 
>             regards, tom lane


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Proposal for a cascaded master-slave replication system
Next
From: Greg Stark
Date:
Subject: Re: New approach to ye olde cross-datatype indexing problem