Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.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
