Horton

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

tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com>

View thread View on postgr.es
From: "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>
To: "k.jamison@fujitsu.com" <k.jamison@fujitsu.com>
Cc: 'Kyotaro Horiguchi' <horikyota.ntt@gmail.com>, "amit.kapila16@gmail.com" <amit.kapila16@gmail.com>, "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>, "andres@anarazel.de" <andres@anarazel.de>, "robertmhaas@gmail.com" <robertmhaas@gmail.com>, "tomas.vondra@2ndquadrant.com" <tomas.vondra@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-10-01T02:40:52Z
Lists: pgsql-hackers 
From: Jamison, Kirk/ジャミソン カーク <k.jamison@fujitsu.com>
> Recovery performance measurement results below.
> But it seems there are overhead even with large shared buffers.
> 
> | s_b   | master | patched | %reg  |
> |-------|--------|---------|-------|
> | 128MB | 36.052 | 39.451  | 8.62% |
> | 1GB   | 21.731 | 21.73   | 0.00% |
> | 20GB  | 24.534 | 25.137  | 2.40% |
> | 100GB | 30.54  | 31.541  | 3.17% |

Did you really check that the optimization path is entered and the traditional path is never entered?

With the following code, when the main fork does not meet the optimization criteria, other forks are not optimized as well.  You want to determine each fork's optimization separately, don't you?

+		/* If blocks are invalid, exit the optimization and execute full scan */
+		if (nTotalBlocks == InvalidBlockNumber)
+			break;


+		else
+			break;
+	}
 	for (i = 0; i < NBuffers; i++)


Regards
Takayuki Tsunakawa

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