Since this discussion seems to have stalled, let me do a quick summary. The goal of this subset of patches is to allow retroactive look up of relations starting from a WAL record. Currently, the WAL record only tracks the relfilenode that it affects, so there are two possibilities:
1. we add some way to find out the relation OID from the relfilenode, 2. we augment the WAL record with the relation OID. Each solution has its drawbacks. For the former, * we need a new cache * we need a new pg_class index * looking up the relation OID still requires some CPU runtime and memory to keep the caches in; run invalidations, etc. For the latter, * each WAL record would become somewhat bigger. For WAL records with a payload of 25 bytes (say insert a tuple which is 25 bytes long) this means about 7% overhead. There are some other issues, but these can be solved. For instance Tom doesn't want a syscache on top of a non-unique index, and I agree on that. But if we agree on this way forward, we can just go a different route by keeping a separate cache layer. So the question is, do we take the overhead of the new index (which means overhead on DML operations -- supposedly rare) or do we take the overhead of larger WAL records (which means overhead on all DDL operations)? Note we can make either thing apply to only people running logical replication. -- Álvaro Herrera 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
