Re: logical changeset generation v6.4

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: logical changeset generation v6.4
Date: 2013-10-26 02:07:44
Message-ID: CA+TgmoaGR8_naFBnMHPdkJ0p9uK5-SkOKXBVntWTJM99FxRRCg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 25, 2013 at 10:58 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> So, I am currently wondering about how to store the "old" tuple, based
> on this. Currently it is stored using the TupleDesc of the index the old
> tuple is based on. But if we want to allow transporting the entire tuple
> that obviously cannot be the only option.
> One option would be to change the stored format based on what's
> configured, using the relation's TupleDesc if FULL is used. But I think
> always using the heap relation's desc is better.

I heartily agree.

> The not-logged columns would then just be represented as NULLs. That
> will make old primary keys bigger if the relation has a high number of
> columns and the key small, but I don't think it matters enough.

Even if it does matter, the cure seems likely to be worse than the disease.

My only other comment is that if NONE is selected, we ought to omit
the old tuple altogether, not store one that is all-nulls. But I bet
you had that in mind anyway.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-10-26 02:11:41 dsm use of uint64
Previous Message Thomas Munro 2013-10-25 22:19:02 Re: CLUSTER FREEZE