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

Re: Seq scans status update

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Seq scans status update
Date: 2007-05-30 18:27:46
Message-ID: 465DC222.80309@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-patches
Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>>> 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.
> 
>> True, except that with the synchronized scans patch two synchronized 
>> scans will pin the buffer twice.
> 
> Hmm.  But we probably don't want the same buffer in two different
> backends' rings, either.  You *sure* the sync-scan patch has no
> interaction with this one?

A buffer is only put to the ring when it's requested with 
StrategyGetBuffer. If a page is requested with ReadBuffer, and it's in 
cache already, it won't be put in the ring. When multiple scanners are 
scanning synchronously, they will all use their own, distinct rings when 
reading buffers into the cache, and "peek" into the buffers in other 
backend's rings for pages that others read to the buffer cache.

I'm going to test the interactions in more detail...

> One other question: I see the patch sets the threshold for switching
> from normal to ring-buffer heapscans at table size = NBuffers.  Why
> so high?  I'd have expected maybe at most NBuffers/4 or NBuffers/10.
> If you don't want a seqscan blowing out your buffer cache, you surely
> don't want it blowing out 90% of the cache either.

NBuffers is the maximum value that makes sense; if you're scanning more 
than NBuffers, the scan is definitely not going to fit in 
shared_buffers. Anything less than that and we might be causing harm to 
some use cases, so I chose that for the time being.

Simon argued for a GUC variable, and Jeff's patch as it stands 
introduces one. I'm not sure we want it but if we do, we should use the 
same variable to control both the sync scan and cache replacement 
policy. It's essentially "how large a scan do you expect to fit in 
shared_buffers?"

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2007-05-30 18:39:46
Subject: Re: WIP: 2nd-generation buffer ring patch
Previous:From: Heikki LinnakangasDate: 2007-05-30 18:18:56
Subject: Re: WIP: 2nd-generation buffer ring patch

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