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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?