Re: Remove xmin and cmin from frozen tuples

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: 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 13:45:40
Message-ID: 20050901134540.GC28356@surnet.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 31, 2005 at 09:14:42PM -0700, Josh Berkus wrote:

> > One thing that comes to mind is that this makes somewhat easier to build
> > a tool to write pre-built tables, for bulk-loading purposes. You just
> > construct the binary file with the HEAP_FROZEN bit set, and then attach
> > the file to a dummy table. (Then again, you can do it today, using a
> > Xmin of FrozenTransactionId. I wonder why the Bizgres people isn't
> > advocating a tool to do that. It is very hard to do with user-defined
> > types, but for BI/DW you mostly don't need those, do you?)
>
> Hmmm ... can you expand on this a little? We'd discussed "frozen partitions"
> but hadn't thought to get around to them for a while, expecting the kind of
> issues which Tom just raised.

What issues did he raise on this?

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.

Note that this is a very different business from skipping the Xmin and
Cmin from the tuple header -- in fact, there's no relation to that at
all.

--
Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com
FOO MANE PADME HUM

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey E. Koposov 2005-09-01 14:14:11 8.1beta, Subtle bug in COPY in Solaris systems
Previous Message Tom Lane 2005-09-01 13:35:35 Re: Minimally avoiding Transaction Wraparound in VLDBs