At Tue, 8 Dec 2020 16:28:41 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in
> On Tue, Dec 8, 2020 at 12:13 PM tsunakawa.takay@fujitsu.com
> <tsunakawa.takay@fujitsu.com> wrote:
> >
> > From: Jamison, Kirk/ジャミソン カーク <k.jamison@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
accessthose TOAST relfilenodes because the inserted data was stored in the main storage. But TRUNCATE always truncates
allthe three relfilenodes. So, the standby had not opened the relfilenode for the TOAST stuff or cached its size when
replayingthe 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
ideato 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). TOAST
relations are not accessed until we insert/update/retrive the values
in it.
An ugly way to cope with it would be to let other smgr functions
manage the cached value, for example, by calling smgrnblocks while
InRecovery. Or letting smgr remember the maximum block number ever
accessed. But we cannot fully rely on that since smgr can be closed
midst of a session and smgr doesn't offer such persistence. In the
first place smgr doesn't seem to be the place to store such persistent
information.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center