At Wed, 6 Feb 2019 06:29:15 +0000, "Tsunakawa, Takayuki" <tsunakawa.ta...@jp.fujitsu.com> wrote in <0A3221C70F24FB45833433255569204D1FB955DF@G01JPEXMBYT05> > From: Jamison, Kirk [mailto:k.jami...@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 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