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
is25 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
