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

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: [HACKERS] mdnblocks is an amazing time sink in huge relations
Дата
Msg-id 001301bf1cf8$555404e0$2801007e@cadzone.tpf.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] mdnblocks is an amazing time sink in huge relations  (Vadim Mikheev <vadim@krs.ru>)
Список 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
isstill 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
SnapshotNowcouldn'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@tpf.co.jp


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] New psql startup banner
Следующее
От: Tom Lane
Дата:
Сообщение: Path-length follies