Re: dump/restore doesn't preserve row ordering? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: dump/restore doesn't preserve row ordering?
Date
Msg-id 1591.1472003023@sss.pgh.pa.us
Whole thread Raw
In response to Re: dump/restore doesn't preserve row ordering?  (Andres Freund <andres@anarazel.de>)
Responses Re: dump/restore doesn't preserve row ordering?  (Kevin Grittner <kgrittn@gmail.com>)
List pgsql-hackers
Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: neha khatri
Date:
Subject: Re: New SQL counter statistics view (pg_stat_sql)
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: Re: [RFC] Change the default of update_process_title to off