Skip site navigation (1) Skip section navigation (2)

Re: Seq scans status update

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Seq scans status update
Date: 2007-05-30 19:21:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Heikki Linnakangas <heikki(at)enterprisedb(dot)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

In response to

pgsql-patches by date

Next:From: Peter EisentrautDate: 2007-05-30 19:23:32
Subject: Re: boolean <=> text explicit casts
Previous:From: Jeff DavisDate: 2007-05-30 19:08:41
Subject: Re: Seq scans status update

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group