Re: [HACKERS] dump/restore doesn't preserve row ordering?

On Tue, Aug 23, 2016 at 8:43 PM, Tom Lane wrote: > It's interesting that nobody has complained about this behavior. We have been known to emphasize that unless you have an ORDER BY clause at the outermost level of a query, there is no guarantee about the order of rows

Re: [HACKERS] dump/restore doesn't preserve row ordering?

Andres Freund writes: > On 2016-08-23 17:22:03 -0400, Tom Lane wrote: >> I can't immediately think of a reason for this. In everyday >> updates you could theorize about effects like autovacuum >> asynchonously updating the FSM, but surely the FSM should have no >> impact on

Re: [HACKERS] dump/restore doesn't preserve row ordering?

On 2016-08-23 17:22:03 -0400, Tom Lane wrote: > I happened to notice, while experimenting with the data set used > in the SPGIST-for-inet thread, that loading the supplied pg_dump > script and immediately dumping it does not reproduce the row order > appearing in the original dump script. I

[HACKERS] dump/restore doesn't preserve row ordering?

I happened to notice, while experimenting with the data set used in the SPGIST-for-inet thread, that loading the supplied pg_dump script and immediately dumping it does not reproduce the row order appearing in the original dump script. I thought maybe this had something to do with the