Skip site navigation (1) Skip section navigation (2)

Re: Seq scans status update

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Seq scans status update
Date: 2007-05-28 20:48:41
Message-ID: 10095.1180385321@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> A point I have not figured out how to deal with is that in the patch as
>> given, UnpinBuffer needs to know the strategy; and getting it that info
>> would make the changes far more invasive.  But the patch's behavior here
>> is pretty risky anyway, since the strategy global at the time of unpin
>> might have nothing to do with how it was set when the buffer was
>> acquired.

> It's assumed that the same strategy is used when unpinning, which is 
> true for the current usage (and apparently needs to be documented).

I don't believe that for a moment.  Even in the trivial heapscan case,
the last pin is typically dropped during a tupleslot clear operation
sometime after the scan itself has moved on to the next page.  In a more
general context (such as parallel heapscan and indexscan on a rel) it's
certainly too risky to assume it.

> Normally buffers that are in the ring are recycled quickly, in which 
> case the usage_count will always be increased from 0->1 in UnpinBuffer, 
> regardless of the check. The check is there to avoid inflating the 
> usage_count on buffers that happened to be already in shared_buffers.

A heapscan would pin the buffer only once and hence bump its count at
most once, so I don't see a big problem here.  Also, I'd argue that
buffers that had a positive usage_count shouldn't get sucked into the
ring to begin with.

> If we figure out another way to deal with the COPY usage_count, maybe we 
> could remove the check altogether. I've been thinking of changing COPY 
> anyway so that it always kept the last page it inserted to pinned, to 
> avoid the traffic to buffer manager on each tuple.

This is getting fairly invasive for a part of the patch you've not
justified at all yet...

> Let me know if you want me to make changes and submit a new version.

I can work on this stuff; please do the tests to show whether it's worth
handling COPY TO REL, and keep on with Jeff's patch.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Simon RiggsDate: 2007-05-28 20:56:15
Subject: Re: [PATCHES] Reviewers Guide to DeferredTransactions/TransactionGuarantee
Previous:From: Simon RiggsDate: 2007-05-28 20:48:39
Subject: Re: Logging checkpoints and other slowdown causes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group