Re: non-transactional pg_class

[Reposting to the correct list, sorry if it's duplicated]

Tom Lane wrote:

> 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.

First attempt at realizing this idea.  pg_ntclass is a relation of a new
relkind, RELKIND_NON_TRANSACTIONAL (ideas for shorter names welcome).
In pg_class, we store a TID to the corresponding tuple.  The tuples are
not cached; they are obtained by heap_fetch() each time they are
requested.  This may be worth reconsideration.

heap_update refuses to operate on a non-transactional catalog, because
there's no (easy) way to update pg_class accordingly.  This normally
shouldn't be a problem.  vac_update_relstats updates the tuple by
using the new heap_inplace_update call.

VACUUM FULL also refuses to operate on these tables, and ANALYZE
silently skips them.  Only plain VACUUM cleans them.

Note that you can DELETE from pg_ntclass.  Not sure if we should
disallow it somehow, because it's not easy to get out from that if you
do.

Regression test pass; I updated the stats test because it was accessing
pg_class.relpages.  So there's already a test to verify that it's
working.

No documentation yet.


There are several warts needed to make it all work:

1. I had to add a "typedef" to pg_class.h to put ItemPointerData in
FormData_pg_class, because the C struct doesn't recognize "tid" but the
bootstrapper does not recognize ItemPointerData as a valid type.  I find
this mighty ugly because it will have side effects whenever we #include
pg_class.h.  Suggestions welcome.

2. During bootstrap, RelationBuildLocalRelation creates nailed relations
with hardcoded TID=(0,1).  This is because we don't have access to
pg_class yet, so we can't find the real pointer; and furthermore, we are
going to fix the entries later in the bootstrapping process.

3. The whole VACUUM/VACUUM FULL/ANALYZE relation list stuff is pretty
ugly as well; and autovacuum is skipping pg_ntclass (really all
non-transactional catalogs) altogether.  We could improve the situation
by introducing some sort of struct like {relid, relkind}, so that
vacuum_rel could know what relkind to expect, and it could skip
non-transactional catalogs cleanly in vacuum full and analyze.

I appreciate any comments.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support