Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option

On 26.08.2026 02:44, Fujii Masao wrote:
> On Wed, Aug 26, 2026 at 6:00 AM Jochen Bandhauer <jb(at)jbitc(dot)de> wrote:
>> Am 25. August 2026 21:57:44 MESZ schrieb Nathan Bossart <nathandbossart(at)gmail(dot)com>:
>>> Does this one deserve a mention on the open items wiki [0]?
>>>
>>> [0] https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
>>>
>> I think yes. It's not critical to the functionality, but the verbose output is not correct.
> I agree that this should be fixed, but I wonder whether this is entirely
> new in v19.
>
> AFAICS, the same kind of misleading "removable" count can also occur with
> CLUSTER USING INDEX in v18 and older releases, since the count depends
> on the scan path. The CONCURRENTLY case is new, but the USING INDEX
> case does not seem to be.
>
> So I'm not sure this should be considered a v19 blocker. Perhaps
> documenting this limitation for now would be sufficient?
>
> Regards,
>
I have taken a closer look at this today and I found that the
"removable" count was probably influenced by page pruning in my original
bug report. This can also be seen with the cluster command in v18. I
would propose to add these lines to the Notes section of the cluster and
repack command documentation:

The number of removable row versions shown in the verbose output should
not be considered a definitive measure of all dead tuples in the table.
It reflects the number of dead tuples encountered by the specific
scanning method (e.g., an index scan) that was used to rebuild the
table. In some cases, dead tuples may be physically removed from the
heap (pruned) before they are even encountered, further influencing this
count.

What do you think?

Jochen

--
Mit freundlichen Grüßen

Jochen Bandhauer
+49 (0)176 29390012
www.jbitc.de