Horton

RE: [Patch] Optimize dropping of relation buffers using dlist

Tang, Haiying <tanghy.fnst@cn.fujitsu.com>

View thread View on postgr.es
From: "Tang, Haiying" <tanghy.fnst@cn.fujitsu.com>
To: "Jamison, Kirk" <k.jamison@fujitsu.com>, "Tsunakawa, Takayuki" <tsunakawa.takay@fujitsu.com>, 'Amit Kapila' <amit.kapila16@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-12-25T02:23:21Z
Lists: pgsql-hackers 
Hi Kirk,


>Perhaps there is a confusing part in the presented table where you indicated master(512), master(256), master(128). 
>Because the master is not supposed to use the BUF_DROP_FULL_SCAN_THRESHOLD and just execute the existing default full scan of NBuffers.
>Or I may have misunderstood something?

Sorry for your confusion, I didn't make it clear. I didn't use BUF_DROP_FULL_SCAN_THRESHOLD for master. 
Master(512) means the test table amount in master is same with patched(512), so does master(256) and master(128).
I meant to mark 512/256/128 to distinguish results in master for the three threshold(applied in patches) .

Regards
Tang

Commits

  1. Fix size overflow in calculation introduced by commits d6ad34f3 and bea449c6.

  2. Optimize DropRelFileNodesAllBuffers() for recovery.

  3. Optimize DropRelFileNodeBuffers() for recovery.

  4. Cache smgrnblocks() results in recovery.

  5. Add a check to prevent overwriting valid data if smgrnblocks() gives a