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

> 
> Hiroshi Inoue wrote:
> > 
> > > 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?
> > >
> > 
> > Does this mean the following ?
> > 
> > 1. shared cache holds committed system tuples.
> > 2. private cache holds uncommitted system tuples.
> > 3. relpages of shared cache are updated immediately by
> >     phisical change and corresponding buffer pages are
> >     marked dirty.
> > 4. on commit, the contents of uncommitted tuples except
> >    relpages,reltuples,... are copied to correponding tuples
>               ^^^^^^^^^
> reltuples in shared catalog cache (SCC) will be updated!
> If transaction inserted some tuples then SCC->reltuples
> will be incremented, etc.
>

System tuples are only modifiled or (insert and delet)ed like
user tuples when reltuples are updated ?
If only modified,we couldn't use it in SERIALIZABLE mode.
> >    in shared cache and the combined contents are
> >    committed.
> > 
> > If so,catalog cache invalidation would be no longer needed.
> 
> I never liked our invalidation code -:)
> 
> > But synchronization of the step 4. may be difficult.
> 
> What's easy in this life? -:)
>

As for relpages(block count),my first thought was that
PostgreSQL relation files have their control data on their
first page, I was surprised to know there's no such data.

Seems catalog cache sharing is another issue as Tom
says.  Of cource it's unnatural to hold separate catalog
cache.

I will be absent this week after now.
I would think for a while.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp