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

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-patches by date

Next:From: Ron MayerDate: 2008-01-29 21:59:05
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Previous:From: Kevin GrittnerDate: 2008-01-29 20:35:36
Subject: Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable

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