Re: In-order pg_dump (or in-order COPY TO)
| От | Ron Johnson |
|---|---|
| Тема | Re: In-order pg_dump (or in-order COPY TO) |
| Дата | |
| Msg-id | CANzqJaAbzGqQK7b6jF-0nuvCf6_JyD7AkSHWqbY4NnP5adfeRg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: In-order pg_dump (or in-order COPY TO) ("David G. Johnston" <david.g.johnston@gmail.com>) |
| Ответы |
Re: In-order pg_dump (or in-order COPY TO)
|
| Список | pgsql-general |
On Tue, Aug 26, 2025 at 4:31 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Tue, Aug 26, 2025 at 12:43 PM Dimitrios Apostolou <jimis@gmx.net> wrote:Could the
row-order have changed when doing COPY FROM with pg_restore?There is no reliable, meaningful, row ordering when it comes to the physical files. Sure, cluster does make an attempt, but it is quite limited in practice.
A *logical* dump of data shouldn't be affected by on-disk order.
Internal representation shouldn't affect the output.The logical dump has no ordering - it will come out however it comes out. "COPY <table> TO ..." doesn't have an order by clause - there is no way to make or communicate to it that ordering is important.
Doesn't COPY TO copy out records in the order they appeared in the physical files? That _seems_ to mean that the records laid down by COPY FROM should be in the same order as they were in the old dump files.
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
В списке pgsql-general по дате отправления: