On Tue, Apr 16, 2019 at 4:47 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > > On Mon, Apr 15, 2019 at 1:13 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> I have a very strong feeling that this patch was not fully baked. > > > I think you're right, but I don't understand the comment in the > > preceding paragraph. How does this problem prevent tupgone from > > getting set? > > My point is that I suspect that tupgone *shouldn't* get set. > It's not (going to be) gone. > > > It looks to me like nleft_dead_tuples should be ripped out. > > That was pretty much what I was thinking too.
tups_vacuumed counts not only (1)dead-but-not-yet-removable tuple but also HOT-pruned tuples. These HOT-pruned tuples include both (2)the tuples we removed both its itemid and tuple storage and the tuples (3)we removed only its tuple storage and marked itemid as dead. So we cannot add tups_vacuumed to nkeeps as it includes completely removed tuple like tuples-(2). I added nleft_dead_itemids to count only tuples-(3) and nleft_dead_tuples to count only tuples-(1) for reporting. Tuples-(2) are removed even when index cleanup is disabled. > It makes more sense > just to treat this case identically to dead-but-not-yet-removable. > I have substantial doubts about nleft_dead_itemids being worth > anything, as well. I think that the adding tuples-(3) to nkeeps would be a good idea. If we do that, nleft_dead_tuples is no longer necessary. On the other hand, I think we need nleft_dead_itemids to report how many itemids we left when index cleanup is disabled. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
