Re: Seq scans status update

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

But the flip side of that is you're failing to provide the benefit of
the patch in quite a lot of use-cases where it's clearly beneficial.
I just don't believe that there are very many cases where people will
want a heapscan to eat 90% of their cache.

> 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?"

Well, let's do some experiments and see if there's really any point in
varying the cutover.

            regards, tom lane