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. 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?
--
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
