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?
|
Список | 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 по дате отправления: