Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to