On Fri, Dec 11, 2020 at 5:54 AM k.jami...@fujitsu.com <k.jami...@fujitsu.com> wrote: > > On Thursday, December 10, 2020 8:12 PM, Amit Kapila wrote: > > On Thu, Dec 10, 2020 at 1:40 PM k.jami...@fujitsu.com > > <k.jami...@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. >
I think you are seeing because text datatype allows creating toast storage and your data is small enough to be toasted. > OTOH, > It worked for data type like integer. > It is not related to any datatype, it can happen whenever we don't have any operation on any of the forks after recovery. > So should I still not include that information? > I think we can extend your existing comment like: "Otherwise if the size of a relation fork is not cached, we proceed to a full scan of the whole buffer pool. This can happen if there is no update to a particular fork during recovery." -- With Regards, Amit Kapila.