RE: Cache relation sizes?

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?
Date: 2019-02-06 05:32:38
Message-ID: 4E72940DA2BF16479384A86D54D0988A6F41D0C5@G01JPEXMBKW04
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>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.)

Takeshi Ideriha

In response to

Browse pgsql-hackers by date

  From Date Subject
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