Re: Remove xmin and cmin from frozen tuples

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: Remove xmin and cmin from frozen tuples
Date: 2005-09-01 15:56:10
Message-ID: 20050901155610.GA29642@surnet.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 01, 2005 at 11:08:36AM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.

It may not be faster generating the data in the first place, but you
don't have to vacuum the table, nor you are subject to hint bits
changing, resulting in more unnecessary I/O.

This can't be avoided with COPY, because there's always the chance that
it will fail partway through, so you can't write frozen tuples. With an
external program, you can just dump the invalid line somewhere else and
continue with the rest.

--
Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com
"Just treat us the way you want to be treated + some extra allowance
for ignorance." (Michael Brusser)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2005-09-01 15:57:41 Using multi-locale support in glibc
Previous Message Peter Eisentraut 2005-09-01 15:48:55 Re: prevent encoding conversion recursive error