Thread: sync_seqscans in postgresql.conf
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... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
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. Regards, Ken
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... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
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
"ktm@rice.edu" <ktm@rice.edu> writes:
> On Tue, Dec 20, 2011 at 02:54:32PM +0100, Magnus Hagander wrote:
>>> 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.
Right. It *is* query semantics for people who are depending on getting
the same row order each time they read an unchanging table. Yeah, the
SQL standard implies that that's not guaranteed, but in all PG versions
before we added syncscan, it did work that way, and some people need it
to continue to work that way (it's worth reflecting that syncscan would
break most or all of the regression tests if it had a smaller
granularity). So it is a backwards-compatibility option.
Which is not to say that I like the current GUC classification in
general, but this particular one isn't out of place.
regards, tom lane