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

Andres Freund <andres(at)anarazel(dot)de> 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 where COPY puts stuff when loading into an empty table.

> It seems possible that a larger row didn't fit on a page anymore, then
> later when a new page was is needed for a smaller row, the earlier page
> is found again. Due to RelationGetBufferForTuple() updating the fsm
> when an old target buffer is present:

Ah. That matches the symptoms --- small groups of rows are getting
relocated, seems like. And there's definitely a wide range of row
lengths in this data.

It's interesting that nobody has complained about this behavior.
Maybe the old fogies are all gone ...

regards, tom lane