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
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 |