Re: ARC buffer strategy committed

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ARC buffer strategy committed
Date: 2003-11-13 16:07:23
Message-ID: 3FB3AC3B.8010401@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)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(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2003-11-13 16:17:10 Re: [HACKERS] Proposal for a cascaded master-slave replication system
Previous Message Greg Stark 2003-11-13 15:36:50 Re: New approach to ye olde cross-datatype indexing problem