On Tue, Dec 20, 2011 at 02:54:32PM +0100, Magnus Hagander wrote:
> On Tue, Dec 20, 2011 at 14:47, ktm@rice.edu <ktm@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 <robertmhaas@gmail.com> wrote:
> >> > On Tue, Dec 20, 2011 at 8:35 AM, Magnus Hagander <magnus@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
