|From:||"Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>|
|To:||"Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>, 'Thomas Munro' <thomas(dot)munro(at)enterprisedb(dot)com>|
|Cc:||David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||RE: Cache relation sizes?|
|Views:||Raw Message | Whole Thread | Download mbox|
>From: Jamison, Kirk [mailto:k(dot)jamison(at)jp(dot)fujitsu(dot)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.)
|Next Message||Kyotaro HORIGUCHI||2019-02-06 05:43:34||Re: Protect syscache from bloating with negative cache entries|
|Previous Message||Thomas Munro||2019-02-06 05:22:12||Re: pg11.1: dsa_area could not attach to segment|