Re: tracking commit timestamps - Mailing list pgsql-hackers

From Robert Haas
Subject Re: tracking commit timestamps
Date
Msg-id CA+TgmoaaRWfs7368anV2Z49GdiBT+kpxYjLECD_W=VXJwv92Dg@mail.gmail.com
Whole thread Raw
In response to Re: tracking commit timestamps  (Petr Jelinek <petr@2ndquadrant.com>)
Responses Re: tracking commit timestamps  (Petr Jelinek <petr@2ndquadrant.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_multixact not getting truncated
Next
From: Robert Haas
Date:
Subject: Re: tracking commit timestamps