Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

On Jan 29, 2008 8:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "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.

+1. The plural is important IMHO.

> 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).

+1. The current patch is simple and so far in the cycle, I really
think we should keep it that way.

> 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?

As I stated earlier, I don't really like this argument (we already
broke badly designed applications a few times in the past) but we
really need a way to guarantee that the execution of a query is stable
and doesn't depend on external factors. And the original problem was
to guarantee that pg_dump builds a dump as identical as possible to
the existing data by ignoring external factors. It's now the case with
your patch.
The fact that it allows us not to break existing applications relying
too much on physical ordering is a nice side effect though :).

--
Guillaume