On Fri, Apr 1, 2022 at 12:08 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> After thinking more about this I see there is some value of
> remembering the dead tids in the conveyor belt. Basically, the point
> is if there are multiple indexes and we do the index vacuum for some
> of the indexes and skip for others. And now when we again do the
> complete vacuum cycle that time we will again get all the old dead
> tids + the new dead tids but without conveyor belt we might need to
> perform the multiple cycle of the index vacuum even for the indexes
> for which we had done the vacuum in previous vacuum cycle (if all tids
> are not fitting in maintenance work mem). But with the conveyor belt
> we remember the conveyor belt pageno upto which we have done the index
> vacuum and then we only need to do vacuum for the remaining tids which
> will definitely reduce the index vacuuming passes, right?
I guess you're right, and it's actually a little bit better than that,
because even if the data does fit into shared memory, we'll have to
pass fewer TIDs to the worker to be removed from the heap, which might
save a few CPU cycles. But I think both of those are very small
benefits. If that's all we're going to do with the conveyor belt
infrastructure, I don't think it's worth the effort. I am completely
in agreement with Peter's comments to the effect that the goal here is
to create flexibility, but it feels to me like the particular
development plan we discussed back in late February isn't going to
create enough flexibility to make it worth the effort it takes. It
seems to me we need to find a way to do better than that.
--
Robert Haas
EDB: http://www.enterprisedb.com
