Heikki Linnakangas <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org

Reply via email to