On 08/11/14 03:05, Robert Haas wrote:
On Fri, Nov 7, 2014 at 7:07 PM, Petr Jelinek <p...@2ndquadrant.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
