On Tue, Dec 8, 2020 at 12:13 PM [email protected] <[email protected]> wrote: > > From: Jamison, Kirk/ジャミソン カーク <[email protected]> > > 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. -- With Regards, Amit Kapila.
