On Mon, Feb 16, 2015 at 4:46 AM, Andres Freund <and...@2ndquadrant.com> 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.
You might notice that Heikki is making the same point here that I've attempted to make multiple times in the past: limiting to replication identifier to 2 bytes because that's how much padding space you happen to have available is optimizing for the wrong thing. What we should be optimizing for is consistency and uniformity of design. System catalogs have OIDs, so this one should, too. You're not going to be able to paper over the fact that the column has some funky data type that is unlike every other column in the system. To the best of my knowledge, the statement that there is a noticeable performance cost for those 2 extra bytes is also completely unsupported by any actual benchmarking. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
