From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Autovacuum-induced regression test instability
In-reply-to: <20190416055312.GG2673@paquier.xyz>
References: <17428.1555348950@sss.pgh.pa.us>
 <20190416055312.GG2673@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Tue, 16 Apr 2019 14:53:12 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28185.1555427286.1@sss.pgh.pa.us>
Date: Tue, 16 Apr 2019 11:08:06 -0400
Message-ID: <28186.1555427286@sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> Aren't extra ORDER BY clauses the usual response to tuple ordering?  I
> really think that we should be more aggressive with that.

I'm not excited about that.  The traditional argument against it
is that if we start testing ORDER BY queries exclusively (and it
would have to be pretty nearly exclusively, if we were to take
this seriously) then we'll lack test coverage for queries without
ORDER BY.  Also, regardless of whether you think that regression
test results can be kicked around at will, we are certainly going
to hear complaints from users if traditional behaviors like
"inserting N rows into a new table, then selecting them, gives
those rows back in the same order" go away.  Recall that we had
to provide a way to disable the syncscan optimization because
some users complained about the loss of row-ordering consistency.

			regards, tom lane