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 thought maybe this had > something to do with the heap_multi_insert() optimization that > COPY uses nowadays, but disabling that didn't change it. Further > experimentation says it's been like that since 8.4; 8.3 is the > last version that reproduces the source row order in this test.
That's http://archives.postgresql.org/message-id/CAE2gYzxv8YKEd4O%2B9HUYuQ%3DQMH4pwt9n9cmU-OchV-%3DN8Q7yXQ%40mail.gmail.com ? > 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: /* * Update FSM as to condition of this page, and ask for another page * to try. */ targetBlock = RecordAndGetPageWithFreeSpace(relation, targetBlock, pageFreeSpace, len + saveFreeSpace); that looks like it's even possible without a concurrent autovacuum. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
