Re: [Patch] Optimize dropping of relation buffers using dlist

At Thu, 1 Oct 2020 04:20:27 +0000, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> wrote in
> From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
> > In more detail, if smgrcachednblocks() returned InvalidBlockNumber for
> > any of the forks, we should give up the optimization at all since we
> > need to run a full scan anyway. On the other hand, if any of the
> > forks is smaller than the threshold, we still can use the optimization
> > when we know the accurate block number of all the forks.
>
> Ah, I got your point (many eyes in open source development is nice.) Still, I feel it's better to treat each fork separately, because the inner loop in the traditional path may be able to skip forks that have been already processed in the optimization path. For example, if the forks[] array contains {fsm, vm, main} in this order (I know main is usually put at the beginning), fsm and vm are processed in the optimization path and the inner loop in the traditional path can skip fsm and vm.

I thought that the advantage of this optimization is that we don't
need to visit all buffers? If we need to run a full-scan for any
reason, there's no point in looking-up already-visited buffers
again. That's just wastefull cycles. Am I missing somethig?

> > Still, I prefer to use total block number of all forks since we anyway
> > visit the all forks. Is there any reason to exlucde forks other than
> > the main fork while we visit all of them already?
>
> When the number of cached blocks for a main fork is below the threshold but the total cached blocks of all forks exceeds the threshold, the optimization is skipped. I think it's mottainai.

I don't understand. If we chose to the optimized dropping, the reason
is the number of buffer lookup is fewer than a certain threashold. Why
do you think that the fork kind a buffer belongs to is relevant to the
criteria?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center