Hi,
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).
Must every relation have a tuple in this catalog? Currently it is
useful only for RELATION, INDEX and TOASTVALUE relkinds, so maybe we can
get away with not requiring it for other relkinds.
On the other hand, must this new catalog be boostrapped? We could
initially create RelationDescs with a NULL relation->rd_ntrel, and then
get the tuple from the syscache when somebody tries to read the fields.
I'm envisioning this new catalog have only reltuples and relpages for
now. (I'll add relvacuumxid and relminxid on the relminxid patch, but
they won't be there on the first pass.)
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.)
So there would be three patches:
1. to replace all uses of relation->rd_rel->reltuples and ->relpages
with macros RelationGetReltuples/Relpages.
2. to add the new catalog and syscache, and have the macros get the
tuple from pg_ntclass when first requested. (Also, of course, mods to
the functions that update pg_class.reltuples, etc, so that they also
update pg_ntclass).
3. the relminxid patch
Have I gotten it right?
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
