I wrote: > Xiaoran Wang <fanfuxiaoran@gmail.com> writes: >> Hmm, how about first checking if any invalidated shared messages have been >> accepted, then rechecking the tuple's visibility? >> If there is no invalidated shared message accepted during >> 'toast_flatten_tuple', >> there is no need to do then visibility check, then it can save several >> CPU cycles.
> Meh, I'd just as soon not add the additional dependency/risk of bugs. > This is an expensive and seldom-taken code path, so I don't think > shaving a few cycles is really important.
It occurred to me that this idea might be more interesting if we could encapsulate it right into systable_recheck_tuple: something like having systable_beginscan capture the current SharedInvalidMessageCounter and save it in the SysScanDesc struct, then compare in systable_recheck_tuple to possibly short-circuit that work. This'd eliminate one of the main bug hazards in the idea, namely that you might capture SharedInvalidMessageCounter too late, after something's already happened. However, the whole idea only works for catalogs that have catcaches, and the other users of systable_recheck_tuple are interested in pg_depend which doesn't. So that put a damper on my enthusiasm for the idea.