Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Zeugswetter Andreas ADI SD" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>
Cc: "Euler Taveira de Oliveira" <euler(at)timbira(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Neil Conway" <neilc(at)samurai(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Date: 2008-01-29 19:09:13
Message-ID: 24107.1201633753@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

"Zeugswetter Andreas ADI SD" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at> writes:
> synchronize[d]_seqscan sounds a bit better in my ears than the plural
> synchronize_seqscans.

The plural seems better to me; there's no such thing as a solitary
synchronized scan, no? The whole point of the feature is to affect
the behavior of multiple scans.

BTW, so far as the rest of the thread goes, I'm not necessarily opposed
to exposing the switchover threshold as a tunable. But I think it needs
more thought to design than we can give it in time for 8.3 (because of
the interaction with the buffer access strategy stuff). Also I don't
like having pg_dump manipulating a tuning parameter. I don't see
anything wrong with having both an on/off feature switch and a tunable
in future releases. The feature switch can be justified on grounds
of backwards compatibility quite independently of whether pg_dump uses
it. Or is someone prepared to argue that there are no applications out
there that will be broken if the same query, against the same unchanging
table, yields different results from one trial to the next?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-01-29 19:20:45 Re: Large pgstat.stat file causes I/O storm
Previous Message Cristian Gafton 2008-01-29 19:06:12 Re: Large pgstat.stat file causes I/O storm

Browse pgsql-patches by date

  From Date Subject
Next Message Kevin Grittner 2008-01-29 20:35:36 Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Previous Message Tom Lane 2008-01-29 18:20:27 Re: NUMERIC key word