Re: tracking commit timestamps - Mailing list pgsql-hackers

From Robert Haas
Subject Re: tracking commit timestamps
Date
Msg-id CA+TgmoYK7qgLST35Azt+tuqK=eiP1JYwYJuRerdzcUzVHyiWJg@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 Fri, Nov 7, 2014 at 7:07 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:
> The list of what is useful might be long,

That's FUD.  It might also be short.

> but we can't have everything there
> as there are space constraints, and LSN is another 8 bytes and I still want
> to have some bytes for storing the "origin" or whatever you want to call it
> there, as that's the one I personally have biggest use-case for.
> So this would be ~24bytes per txid already, hmm I wonder if we can pull some
> tricks to lower that a bit.

It won't do to say "let's do the things that I want, and foreclose
forever the things that other people want".  I find it quite hard to
believe that 16 bytes per transaction is a perfectly tolerable
overhead but 24 bytes per transaction will break the bank.  But if
that is really true then we ought to reject this patch altogether,
because it's unacceptable, in any arena, for a patch that only
benefits extensions to consume all of the available bit-space in,
leaving none for future core needs.

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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pg_basebackup fails with long tablespace paths
Next
From: Robert Haas
Date:
Subject: Re: Sequence Access Method WIP