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. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend