Re: logical changeset generation v6.4 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: logical changeset generation v6.4
Date
Msg-id CA+TgmoaGR8_naFBnMHPdkJ0p9uK5-SkOKXBVntWTJM99FxRRCg@mail.gmail.com
Whole thread Raw
In response to Re: logical changeset generation v6.4  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Fri, Oct 25, 2013 at 10:58 AM, Andres Freund <andres@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: CLUSTER FREEZE
Next
From: Robert Haas
Date:
Subject: dsm use of uint64