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