Re: Remove xmin and cmin from frozen tuples

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Remove xmin and cmin from frozen tuples
Дата
Msg-id 12952.1125587316@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Remove xmin and cmin from frozen tuples  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: Remove xmin and cmin from frozen tuples  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: Remove xmin and cmin from frozen tuples  (Josh Berkus <josh@agliodbs.com>)
Re: Remove xmin and cmin from frozen tuples  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> What I'm saying is that you can write a heap file, on which the tuples
> would all have xmin=FrozenTransactionId, xmax=Invalid, and the
> corresponding bits set in the infomask.  This ensures that no matter the
> state of the server, you can plug the file in and all tuples will be
> valid.

> The "only" problem is figuring out how to lay the data in the tuples
> themselves, w.r.t endianness and such.  This is platform-dependent, so
> you have to write code to do it correctly.  In absence of user-defined
> types, this should not be _too_ hard to do.  Of course, such a program
> would in general also be Postgres-version-dependent.

Of course, it's fair to ask whether such a program would be any faster
than binary-mode COPY by the time you got done ... or enough faster to
justify your effort, anyway.

THe only fundamental disadvantage that COPY labors under is having to
write WAL records.  It might be interesting to do something similar to
the recent hacks for CREATE TABLE AS, so that a COPY into a table just
created in the current transaction would skip writing WAL and instead
fsync the table at the end.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew - Supernews
Дата:
Сообщение: Re: TODO item: set proper permissions on non-system schemas
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Remove xmin and cmin from frozen tuples