> But to tell the truth, I'm mostly exercised about the non-unique
> syscache. I think that's simply a *bad* idea.
+1.
I don't think the extra index on pg_class is going to hurt that much, even if we create it always, as long as we use a purpose-built caching mechanism for it rather than forcing it through catcache.
Hmm, does seem like that would be better.
The people who are going to suffer are the ones who create and drop a lot of temporary tables, but even there I'm not sure how visible the overhead will be on real-world workloads, and maybe the solution is to work towards not having permanent catalog entries for temporary tables in the first place. In any case, hurting people who use temporary tables heavily seems better than adding overhead to every insert/update/delete operation, which will hit all users who are not read-only.
Thinks...
If we added a trigger that fired a NOTIFY for any new rows in pg_class that relate to non-temporary relations that would optimise away any overhead for temporary tables or when no changeset extraction was in progress.
The changeset extraction could build a private hash table to perform the lookup and then LISTEN on a specific channel for changes.
That might work better than an index-plus-syscache.
On the other hand, I can't entirely shake the feeling that adding the information into WAL would be more reliable.
I don't really like the idea of requiring the relid on the WAL record. WAL is big enough already and we want people to turn this on, not avoid it.
This is just an index lookup. We do them all the time without any fear of reliability issues.