On Mon, Jan 18, 2021 at 1:10 PM Victor Yegorov <vyego...@gmail.com> wrote: > I must admit, that it's a bit difficult to understand you here (at least for > me). > > I assume that by "bet" you mean flagged tuple, that we marked as such > (should we implement the suggested case). > As heapam will give up early in case there are no deletable tuples, why do > say, > that "bet" is no longer low? At the end, we still decide between page split > (and > index bloat) vs a beneficial space cleanup.
Well, as I said, there are various ways in which our inferences (say the ones in nbtdedup.c) are likely to be wrong. You understand this already. For example, obviously if there are two duplicate index tuples pointing to the same heap page then it's unlikely that both will be deletable, and there is even a fair chance that neither will be (for many reasons). I think that it's important to justify why we use stuff like that to drive our decisions -- the reasoning really matters. It's very much not like the usual optimization problem thing. It's a tricky thing to discuss. I don't assume that I understand all workloads, or how I might introduce regressions. It follows that I should be extremely conservative about imposing new costs here. It's good that we currently know of no workloads that the patch is likely to regress, but absence of evidence isn't evidence of absence. I personally will never vote for a theoretical risk with only a theoretical benefit. And right now that's what the idea of doing bottom-up deletions in more marginal cases (the page flag thing) looks like. -- Peter Geoghegan
