Re: logical changeset generation v6.4

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: logical changeset generation v6.4
Дата
Msg-id CA+TgmoaGR8_naFBnMHPdkJ0p9uK5-SkOKXBVntWTJM99FxRRCg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: logical changeset generation v6.4  (Andres Freund <andres@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: CLUSTER FREEZE
Следующее
От: Robert Haas
Дата:
Сообщение: dsm use of uint64