Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Zeugswetter Andreas ADI SD" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Heikki Linnakangas" <heikki(at)enterprisedb(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, "Neil Conway" <neilc(at)samurai(dot)com>, "Euler Taveira de Oliveira" <euler(at)timbira(dot)com>
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Date: 2008-01-29 21:00:49
Message-ID: 25718.1201640449@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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?

> If geqo kicks in, we're already there, aren't we?

Yup, and that's one of the reasons we have a way to turn geqo off.
(geqo is actually a good precedent for this --- notice that it has
an on/off switch that's separate from its tuning knobs.)

> Isn't an application which counts on the order of result rows
> without specifying ORDER BY fundamentally broken?

No doubt, but if it's always worked before, people are going to be
unhappy anyway.

Also, it's not just ordering that's at stake. Try

regression=# create table foo as select x from generate_series(1,1000000) x;
SELECT
regression=# select * from foo limit 10000;
x
-------
1
2
3
4
....
regression=# select * from foo limit 10000;
x
-------
7233
7234
7235
7236
....
regression=# select * from foo limit 10000;
x
-------
14465
14466
14467
14468
....

Now admittedly we've never promised LIMIT without ORDER BY to be
well-defined either, but not everybody reads the fine print.
This case is particularly nasty because at smaller LIMIT values
the result *is* consistent, so you might never notice the problem
while testing.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-01-29 21:06:59 Re: Transition functions for SUM(::int2), SUM(::int4, SUM(::int8])
Previous Message Caleb Welton 2008-01-29 20:58:39 Re: Transition functions for SUM(::int2), SUM(::int4, SUM(::int8])

Browse pgsql-patches by date

  From Date Subject
Next Message Ron Mayer 2008-01-29 21:59:05 Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Previous Message Kevin Grittner 2008-01-29 20:35:36 Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable