Alvaro Herrera <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq