Thread

Re: [HACKERS] mdnblocks is an amazing time sink in huge relations

Vadim Mikheev <vadim@krs.ru> — 1999-10-19T04:40:40Z

Tom Lane wrote:
> 
> >> a shared cache for system catalog tuples, which might be a win but I'm
> >> not sure (I'm worried about contention for the cache, especially if it's
> >> protected by just one or a few spinlocks).  Anyway, if we did have one

Commercial DBMSes have this... Isn't it a good reason? -:)

> > But there would be a problem if we use shared catalog cache.
> > Being updated system tuples are only visible to an updating backend
> > and other backends should see committed tuples.
> > On the other hand,an accurate block count should be visible to all
> > backends.
> > Which tuple of a row should we load to catalog cache and update ?
> 
> Good point --- rolling back a transaction would cancel changes to the
> pg_class row, but it mustn't cause the relation's file to get truncated
> (since there could be tuples of other uncommitted transactions in the
> newly added block(s)).
> 
> This says that having a block count column in pg_class is the Wrong
> Thing; we should get rid of relpages entirely.  The Right Thing is a
> separate data structure in shared memory that stores the current
> physical block count for each active relation.  The first backend to
> touch a given relation would insert an entry, and then subsequent
> extensions/truncations/deletions would need to update it.  We already
> obtain a special lock when extending a relation, so seems like there'd
> be no extra locking cost to have a table like this.

I supposed that each backend will still use own catalog 
cache (after reading entries from shared one) and synchronize 
shared/private caches on commit - e.g. update reltuples!
relpages will be updated immediately after physical changes -
what's problem with this?

> Anyone up for actually implementing this ;-) ?  I have other things
> I want to work on...

And me too -:))

Vadim