RE: [Patch] Optimize dropping of relation buffers using dlist
k.jamison@fujitsu.com <k.jamison@fujitsu.com>
From: "k.jamison@fujitsu.com" <k.jamison@fujitsu.com>
To: 'Amit Kapila' <amit.kapila16@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.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-11T00:24:45Z
Lists: pgsql-hackers
On Thursday, December 10, 2020 8:12 PM, Amit Kapila wrote: > On Thu, Dec 10, 2020 at 1:40 PM k.jamison@fujitsu.com > <k.jamison@fujitsu.com> wrote: > > > > Yes, I have tested that optimization works for index relations. > > > > I have attached the V34, following the conditions that we use "cached" > > flag for both DropRelFileNodesBuffers() and DropRelFileNodesBuffers() > > for consistency. > > I added comment in 0004 the limitation of optimization when there are > > TOAST relations that use NON-PLAIN strategy. i.e. The optimization > > works if the data types used are integers, OID, bytea, etc. But for > > TOAST-able data types like text, the optimization will be skipped and force a > full scan during recovery. > > > > AFAIU, it won't take optimization path only when we have TOAST relation but > there is no insertion corresponding to it. If so, then we don't need to mention > it specifically because there are other similar cases where the optimization > won't work like when during recovery we have to just perform TRUNCATE. > Right, I forgot to add that there should be an update like insert to the TOAST relation for truncate optimization to work. However, that is only limited to TOAST relations with PLAIN strategy. I have tested with text data type, with Inserts before truncate, and it did not enter the optimization path. OTOH, It worked for data type like integer. So should I still not include that information? Also, I will remove the unnecessary "cached" from the line that Tsunakawa-san mentioned. I will wait for a few more comments before reuploading, hopefully, the final version & including the test for truncate, Regards, Kirk Jamison
Commits
-
Fix size overflow in calculation introduced by commits d6ad34f3 and bea449c6.
- 519e4c9ee21a 14.0 landed
-
Optimize DropRelFileNodesAllBuffers() for recovery.
- bea449c635c0 14.0 landed
-
Optimize DropRelFileNodeBuffers() for recovery.
- d6ad34f3410f 14.0 landed
-
Cache smgrnblocks() results in recovery.
- c5315f4f4484 14.0 cited
-
Add a check to prevent overwriting valid data if smgrnblocks() gives a
- ffae5cc5a602 8.2.0 cited