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(at)tpf(dot)co(dot)jp