Re: Cache relation sizes?

At Wed, 6 Feb 2019 06:29:15 +0000, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote in <0A3221C70F24FB45833433255569204D1FB955DF(at)G01JPEXMBYT05>
> 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?
>
> Although I haven't looked deeply at Thomas's patch yet, there's currently no place to store the size per relation in shared memory. You have to wait for the global metacache that Ideriha-san is addressing. Then, you can store the relation size in the RelationData structure in relcache.

Just one counter in the patch *seems* to give significant gain
comparing to the complexity, given that lseek is so complex or it
brings latency, especially on workloads where file is scarcely
changed. Though I didn't run it on a test bench.

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

I'm not sure the duration of the 'permanent' there, but it
disappears when server stops. Anyway it doesn't need to be
permanent beyond a server restart.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center