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-21T01:34:23Z
Lists: pgsql-hackers 
From: tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com>
> Can you measure the time DropRelFileNodeBuffers()?  You can call
> GetTimestamp() at the beginning and end of the function, and use
> TimestampDifference() to calculate the difference.  Then, for instance,
> elog(WARNING, "time is | %u.%u", sec, usec) at the end of the function.  You
> can use any elog() print format for your convenience to write shell commands to
> filter the lines and sum up the total.

Before doing this, you can also do "VACUUM (truncate off)" to see which of the garbage collection or relation truncation takes long time.  The relation truncation processing includes not only DropRelFileNodeBuffers() but also file truncation and something else, but it's an easy filter.


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