| From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
|---|---|
| To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
| Cc: | pgsql-hackers(at)postgreSQL(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: [HACKERS] mdnblocks is an amazing time sink in huge relations |
| Date: | 1999-10-20 02:28:23 |
| Message-ID: | 380D28C7.15948078@krs.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
> 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? -:)
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vadim Mikheev | 1999-10-20 02:34:02 | Re: [HACKERS] Re: New developer globe |
| Previous Message | Vince Vielhaber | 1999-10-20 02:05:33 | current_time? |