On Wed, Dec 9, 2020 at 6:32 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > At Tue, 8 Dec 2020 16:28:41 +0530, Amit Kapila <amit.kapil...@gmail.com> > wrote in > > On Tue, Dec 8, 2020 at 12:13 PM tsunakawa.ta...@fujitsu.com > > <tsunakawa.ta...@fujitsu.com> wrote: > > > > > > From: Jamison, Kirk/ジャミソン カーク <k.jami...@fujitsu.com> > > > > Because one of the rel's cached value was false, it forced the > > > > full-scan path for TRUNCATE. > > > > Is there a possible workaround for this? > > > > > > Hmm, the other two relfilenodes are for the TOAST table and index of the > > > target table. I think the INSERT didn't access those TOAST relfilenodes > > > because the inserted data was stored in the main storage. But TRUNCATE > > > always truncates all the three relfilenodes. So, the standby had not > > > opened the relfilenode for the TOAST stuff or cached its size when > > > replaying the TRUNCATE. > > > > > > I'm afraid this is more common than we can ignore and accept the slow > > > traditional path, but I don't think of a good idea to use the cached flag. > > > > > > > I also can't think of a way to use an optimized path for such cases > > but I don't agree with your comment on if it is common enough that we > > leave this optimization entirely for the truncate path. > > Mmm. At least btree doesn't need to call smgrnblocks except at > expansion, so we cannot get to the optimized path in major cases of > truncation involving btree (and/or maybe other indexes). >
AFAICS, btree insert should call smgrnblocks via btree_xlog_insert->XLogReadBufferForRedo->XLogReadBufferForRedoExtended->XLogReadBufferExtended->smgrnblocks. Similarly delete should also call smgrnblocks. Can you be bit more specific related to the btree case you have in mind? -- With Regards, Amit Kapila.
