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

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Vadim Mikheev" <vadim(at)krs(dot)ru>
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-23 01:45:49
Message-ID: 001301bf1cf8$555404e0$2801007e@cadzone.tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>
> But in any case, it seems to me that using shmem for
> shared catalog cache is much worther than for
> shared cache invalidation...
>

I don't like current cache invalidation either.
And shared catalog cache would make it easy to rollback
catalog cache(catalog/relation cache is not rollbacked correct-
ly now).

But there are some problems to implement shared catalog
cache.

1. Relation cache invalidation remains
It has almost same mechanism as catalog cache invaldation.
Cache invaldation is still incomprehensible as a whole.

2. Is it clear how consistency is kept between system tuples ?
It's quite unclear for me and there are 4 anxieties at least.

a. Locking for system tuples is short term(this is for DDL
commands inside transactions). This would break 2-phase
lock easily. Is there another principle instead ?

b. SnapshotNow is used to access system tuples in most
cases. SnapshotNow isn't a real snapshot.
i.e SnapshotNow couldn't guarantee read consistency.

c. Row level locking is not implemented for system tuples yet.

d. AccessShare lock are acquired for system tuples in many
places. But does it have any sense ?

3. If neither relpages nor reltuples is held,are there any other
speeding up things ?

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-10-23 04:46:42 Path-length follies
Previous Message Bruce Momjian 1999-10-23 01:24:55 Re: [HACKERS] New psql startup banner