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

Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

From: "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Zeugswetter Andreas ADI SD" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>, "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-30 02:07:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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 :).


In response to


pgsql-hackers by date

Next:From: Stephen DenneDate: 2008-01-30 02:37:04
Subject: Re: 8.3RC1 on windows missing descriptive Event handle names
Previous:From: Tom LaneDate: 2008-01-30 01:31:07
Subject: Re: Opinions about wording of error messages for bug #3883?

pgsql-patches by date

Next:From: Zoltan BoszormenyiDate: 2008-01-30 08:54:24
Subject: Re: WIP: plpgsql source code obfuscation
Previous:From: Stephen DenneDate: 2008-01-29 22:33:39
Subject: Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable

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