RE: Cache relation sizes?

Поиск
Список
Период
Сортировка
От Ideriha, Takeshi
Тема RE: Cache relation sizes?
Дата
Msg-id 4E72940DA2BF16479384A86D54D0988A6F41D0C5@G01JPEXMBKW04
обсуждение исходный текст
Ответ на RE: Cache relation sizes?  ("Jamison, Kirk" <k.jamison@jp.fujitsu.com>)
Список pgsql-hackers
>From: Jamison, Kirk [mailto:k.jamison@jp.fujitsu.com]

>On the other hand, the simplest method I thought that could also work is to only cache
>the file size (nblock) in shared memory, not in the backend process, since both nblock
>and relsize_change_counter are uint32 data type anyway. If relsize_change_counter
>can be changed without lock, then nblock can be changed without lock, is it right? In
>that case, nblock can be accessed directly in shared memory. In this case, is the
>relation size necessary to be cached in backend?

(Aside from which idea is better.. )
If you want to put relation size on the shared memory, then I don't think caches in backend 
is necessary because every time relation_size is updated you need to invalidate cache 
in backends. At the reference taking shared lock on the cache and at the update taking 
exclusive lock is simple without backend cache. 

>(2) Is the MdSharedData temporary or permanent in shared memory?
That data structure seems to initialize at the time of InitPostgre, which means it's permanent
because postgres-initialized-shared-memory doesn't have a chance to drop it as far as I know.
(If you want to use temporary data structure, then other mechanism like dsm/dsa/dshash is a candidate.)

Regards,
Takeshi Ideriha

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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: pg11.1: dsa_area could not attach to segment
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Protect syscache from bloating with negative cache entries