Re: non-transactional pg_class

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> I've been taking a look at what's needed for the non-transactional part
> of pg_class. If I've understood this correctly, we need a separate
> catalog, which I've dubbed pg_ntclass (better ideas welcome), and a new
> pointer in RelationData to hold a pointer to this new catalog for each
> relation. Also a new syscache needs to be created (say, NTRELOID).

Do you really need both a relcache slot and a syscache? Seems
redundant. For that matter, do you need either? Both the relcache and
syscache operate on the assumption of transactional updates, so I think
that you're going to have semantic problems using the caches to hold
these tuples. For instance we don't broadcast any sinval update
messages from a rolled-back transaction.

> On the other hand, must this new catalog be boostrapped?

If relation creation or row insertion is going to try to write into it,
then yes. You could get away with not writing a row initially as long
as the rows only hold reltuples/relpages, but I think that would stop
working as soon as you put the "unfreeze" code in.

> Obviously the idea is that we would never heap_update tuples there; only
> heap_inplace_update (and heap_insert when a new relation is created.)

Initial insertion (table CREATE) and deletion (table DROP) would both
have to be transactional operations. This may be safe because we'd hold
exclusive lock on the table and so no one else would be touching the
table's row, but it bears thinking about, because after all the whole
point of the exercise is to keep transactional and nontransactional
updates separate.

What happens if someone tries to do a manual UPDATE in this catalog?
Maybe this can be in the category of "superusers should know enough not
to do that", but I'd like to be clear on exactly what the consequences
might be. Perhaps "nontransactional catalogs" should be a new relkind
that we disallow normal updates on.

If we do disallow normal updates (and VACUUM FULL too, probably) then
it'd be possible to say that a given entry has a fixed TID for its
entire lifespan. Then we could store the TID in the table's regular
pg_class entry and dispense with any indexes. This would be
advantageous if we end up concluding that we can't use the syscache
mechanism (as I suspect that we can't), because we're going to be making
quite a lot of fetches from this catalog. A direct fetch by TID would
be a lot cheaper than an index search.

regards, tom lane