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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
