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

Re: CLUSTER and synchronized scans and pg_dump et al

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CLUSTER and synchronized scans and pg_dump et al
Date: 2008-01-28 22:36:43
Message-ID: 1201559803.10057.637.camel@dogma.ljc.laika.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, 2008-01-27 at 12:45 -0500, Tom Lane wrote:
> Maybe a GUC variable to enable/disable syncscan?

The first iterations of the patch included a GUC. 

I don't have any objection to re-introducing a GUC to enable/disable it.
However, I would suggest that it defaults to "on", because:

1. There aren't many cases where you'd want it to be off, and this
particular case with pg_dump is the best one that I've heard of (thanks
Greg). We want people who install 8.3 to see a boost without lots of
tuning, if possible.
2. It only turns on for tables over 25% of shared buffers anyway.

Introducing GUCs reintroduces the same questions that were discussed
before. 

1. Should the 25% figure be tunable as well? 
2. Remember that the 25% figure is also tied to Simon and Heikki's
buffer recycling patch (buffer ring patch). Should they be configurable
independently? Should they be tied together, but configurable?

The simplest solution, in my opinion, is something like:

large_scan_threshold = 0.25 # set to -1 to disable

Where a scan of any table larger than (large_scan_threshold *
shared_buffers) employs both synchronized scans and buffer recycling. We
may implement other large scan strategies in the future.

Regards,
	Jeff Davis


In response to

pgsql-hackers by date

Next:From: Jeff DavisDate: 2008-01-28 22:38:50
Subject: Re: CLUSTER and synchronized scans and pg_dump et al
Previous:From: Jeff DavisDate: 2008-01-28 22:11:43
Subject: Re: RFC: array_agg() per SQL:200n

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