RE: Cache relation sizes?

Поиск
Список
Период
Сортировка
От Tsunakawa, Takayuki
Тема RE: Cache relation sizes?
Дата
Msg-id 0A3221C70F24FB45833433255569204D1FB955DF@G01JPEXMBYT05
обсуждение исходный текст
Ответ на RE: Cache relation sizes?  ("Jamison, Kirk" <k.jamison@jp.fujitsu.com>)
Ответы Re: Cache relation sizes?  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список 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?

Although I haven't looked deeply at Thomas's patch yet, there's currently no place to store the size per relation in
sharedmemory.  You have to wait for the global metacache that Ideriha-san is addressing.  Then, you can store the
relationsize in the RelationData structure in relcache.
 



> (2) Is the MdSharedData temporary or permanent in shared memory?
> from the patch:
>  typedef struct MdSharedData
>  {
>      /* XXX could have an array of these, and use rel OID % nelements?
> */
>      pg_atomic_uint32    relsize_change_counter;
>  } MdSharedData;
> 
>  static MdSharedData *MdShared;

Permanent in shared memory.


Regards
Takayuki Tsunakawa


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

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Protect syscache from bloating with negative cache entries
Следующее
От: Pavan Deolasee
Дата:
Сообщение: A separate table level option to control compression