Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

Zeugswetter Andreas OSB sIT <andreas.zeugswetter@s-itsolutions.at>

From: "Zeugswetter Andreas ADI SD" <Andreas.Zeugswetter@s-itsolutions.at>

To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Euler Taveira de Oliveira" <euler@timbira.com>

Cc: "Simon Riggs" <simon@2ndquadrant.com>, "Heikki Linnakangas" <heikki@enterprisedb.com>, "Neil Conway" <neilc@samurai.com>, "Gregory Stark" <stark@enterprisedb.com>, "Jonah H. Harris" <jonah.harris@gmail.com>, <pgsql-hackers@postgresql.org>

Date: 2008-01-29T15:37:34Z

Lists: pgsql-hackers

> > +1. If we go with 'enable_sync_seqcans' for 8.3, and in a future
release 
> > cycle we do test the cases Simon described above and we agree we
need to 
> > do a fine tune to benefit from this feature, we will need to
deprecate 
> > 'enable_sync_seqscans' and invent another one
(sync_seqscans_threshold). 
> > Looking at this perpective, IMHO we should go with the number (0.25)

> > instead of the boolean.
> 
> Surely the risk-of-needing-to-deprecate argument applies ten times
more
> strongly to a number than a boolean.

Yes, I would expect the tuning to be more system than user specific.
So imho a boolean userset would couple well with a tuning guc, that
may usefully not be userset (if we later discover a need for tuning at
all).

so +1 for the bool. 

synchronize[d]_seqscan sounds a bit better in my ears than the plural
synchronize_seqscans.
To me the latter somehow suggests influece on the whole cluster,
probably not 
worth further discussion though, so if someone says no, ok.

Andreas