From: Kyotaro Horiguchi <[email protected]>
> 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.
> 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.
Regards
Takayuki Tsunakawa
