On 2015-02-19 00:49:50 +0100, Petr Jelinek wrote:
> On 16/02/15 10:46, Andres Freund wrote:
> >On 2015-02-16 11:34:10 +0200, Heikki Linnakangas wrote:
> >
> >>At a quick glance, this basic design seems workable. I would suggest
> >>expanding the replication IDs to regular 4 byte oids. Two extra bytes is a
> >>small price to pay, to make it work more like everything else in the system.
> >
> >I don't know. Growing from 3 to 5 byte overhead per relevant record (or
> >even 0 to 5 in case the padding is reused) is rather noticeable. If we
> >later find it to be a limit (I seriously doubt that), we can still
> >increase it in a major release without anybody really noticing.
> >
>
> I agree that limiting the overhead is important.
>
> But I have related though about this - I wonder if it's worth to try to map
> this more directly to the CommitTsNodeId.
Maybe. I'd rather go the other way round though;
replication_identifier.c/h's stuff seems much more generic than
CommitTsNodeId.
> I mean it is currently using that
> for the actual storage, but I am thinking of having the Replication
> Identifiers be the public API and the CommitTsNodeId stuff be just hidden
> implementation detail. This thought is based on the fact that CommitTsNodeId
> provides somewhat meaningless number while Replication Identifiers give us
> nice name for that number. And if we do that then the type should perhaps be
> same for both?
I'm not sure. Given that this is included in a significant number of
recordsd I'd really rather not increase the overhead as described
above. Maybe we can just limit CommitTsNodeId to the same size for now?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
