Skip site navigation (1) Skip section navigation (2)

Re: non-transactional pg_class

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Hackers <pgsql-patches(at)postgresql(dot)org>
Subject: Re: non-transactional pg_class
Date: 2006-06-05 13:14:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
[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

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

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                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

pgsql-hackers by date

Next:From: Jim NasbyDate: 2006-06-05 13:14:31
Subject: Re: Faster Updates
Previous:From: Jim NasbyDate: 2006-06-05 13:10:07
Subject: Re: Faster Updates

pgsql-patches by date

Next:From: Zdenek KotalaDate: 2006-06-05 16:55:50
Subject: Re: Allow commenting of variables in postgresql.conf to -
Previous:From: Bruce MomjianDate: 2006-06-05 04:27:04
Subject: Re: Re [HACKERS]: Still not happy with psql's multiline history behavior

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group