"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
