Re: tracking commit timestamps

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: tracking commit timestamps
Дата
Msg-id CA+TgmoaaRWfs7368anV2Z49GdiBT+kpxYjLECD_W=VXJwv92Dg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: tracking commit timestamps  (Petr Jelinek <petr@2ndquadrant.com>)
Ответы Re: tracking commit timestamps  (Petr Jelinek <petr@2ndquadrant.com>)
Список pgsql-hackers
On Mon, Nov 10, 2014 at 8:39 AM, Petr Jelinek <petr@2ndquadrant.com> wrote:
> I did the calculation above wrong btw, it's actually 20 bytes not 24 bytes
> per record, I am inclined to just say we can live with that.

If you do it as 20 bytes, you'll have to do some work to squeeze out
the alignment padding.  I'm inclined to think it's fine to have a few
extra padding bytes here; someone might want to use those for
something in the future, and they probably don't cost much.

> Since we agreed that the (B) case is not really feasible and we are doing
> the (C), I also wonder if extradata should be renamed to nodeid (even if
> it's not used at this point as nodeid). And then there is question about the
> size of it, since the nodeid itself can live with 2 bytes probably ("64k of
> nodes ought to be enough for everybody" ;) ).
> Or leave the extradata as is but use as reserved space for future use and
> not expose it at this time on SQL level at all?

I vote for calling it node-ID, and for allowing at least 4 bytes for
it.  Penny wise, pound foolish.

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_multixact not getting truncated
Следующее
От: Robert Haas
Дата:
Сообщение: Re: tracking commit timestamps