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

Re: [PATCHES] Proposed patch: synchronized_scanningGUCvariable

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Zeugswetter Andreas ADI SD" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "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_scanningGUCvariable
Date: 2008-01-29 20:35:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
>>> On Tue, Jan 29, 2008 at  1:09 PM, in message <24107(dot)1201633753(at)sss(dot)pgh(dot)pa(dot)us>,
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?
Isn't an application which counts on the order of result rows
without specifying ORDER BY fundamentally broken?

In response to


pgsql-hackers by date

Next:From: Caleb WeltonDate: 2008-01-29 20:58:39
Subject: Re: Transition functions for SUM(::int2), SUM(::int4, SUM(::int8])
Previous:From: Tom LaneDate: 2008-01-29 20:12:41
Subject: Re: Large pgstat.stat file causes I/O storm

pgsql-patches by date

Next:From: Tom LaneDate: 2008-01-29 21:00:49
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Previous:From: Tom LaneDate: 2008-01-29 19:09:13
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

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