RE: Cache relation sizes? - Mailing list pgsql-hackers

From Ideriha, Takeshi
Subject RE: Cache relation sizes?
Date
Msg-id 4E72940DA2BF16479384A86D54D0988A6F41D0C5@G01JPEXMBKW04
Whole thread Raw
In response to RE: Cache relation sizes?  ("Jamison, Kirk" <k.jamison@jp.fujitsu.com>)
List 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 by date:

Previous
From: Thomas Munro
Date:
Subject: Re: pg11.1: dsa_area could not attach to segment
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Protect syscache from bloating with negative cache entries