Re: tracking commit timestamps

On 08/11/14 03:05, Robert Haas wrote:
> On Fri, Nov 7, 2014 at 7:07 PM, Petr Jelinek <petr(at)2ndquadrant(dot)com> wrote:
>> 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.
>

That's not what I said. I am actually ok with adding the LSN if people
see it useful.
I was just wondering if we can make the record smaller somehow - 24bytes
per txid is around 96GB of data for whole txid range and won't work with
pages smaller than ~4kBs unless we add 6 char support to SLRU (which is
not hard and we could also not allow track_commit_timestamps to be
turned on with smaller pagesize...).

I remember somebody was worried about this already during the original
patch submission and it can't be completely ignored in the discussion
about adding more stuff into the record.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services