On Tue, Dec 20, 2011 at 02:54:32PM +0100, Magnus Hagander wrote: > On Tue, Dec 20, 2011 at 14:47, k...@rice.edu <k...@rice.edu> wrote: > > On Tue, Dec 20, 2011 at 02:41:54PM +0100, Magnus Hagander wrote: > >> On Tue, Dec 20, 2011 at 14:38, Robert Haas <robertmh...@gmail.com> wrote: > >> > On Tue, Dec 20, 2011 at 8:35 AM, Magnus Hagander <mag...@hagander.net> > >> > wrote: > >> >> Is there any reason why the setting synchronize_seqscans is in the > >> >> section "version/platform compatibility" in postgresql.conf? Is it > >> >> just because nobody could find a better place for it? ;) It seems a > >> >> bit wrong to me... > >> > > >> > Presumably the thought was that you would turn it off to restore that > >> > existed in older versions of PostgreSQL. Doesn't seem much different > >> > from default_with_oids or lo_compat_privileges. > >> > >> Seems very different to me - those change *what* happens when you do > >> certain things. sync_seqscans is just a performance tuning option, no? > >> It doesn't actually change the semantics of any operations... > >> > > > > In a query without enforced orders, the returned rows will come out in > > a possibly different order each time the query runs. I know it is bad > > coding to depend on things like that, but it is out there... So in those > > cases it is not just semantics. > > Yes, but they may also come out in a different order if you run the > same query again 5 minutes later... >
If the sequential scans always start at the beginning of the table, which was true before the sync-ed scans ability, the order is basically fixed for a large set of queries if you do not modify the data. With sync-ed scans, every repetition of the query will depend on where the scan starts in the data set. At least that is what I remember happening during the original testing of that feature, which is a great feature. Regards, Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
