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

From: Jochen Bandhauer <jb(at)jbitc(dot)de>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: repack with verbose output: not showing the number of removable row versions when using USING INDEX or CONCURRENTLY option
Date: 2026-08-31 11:20:30
Message-ID: 2e7e3d82-9526-49c4-8ab0-15fd9c0c9696@jbitc.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 26.08.2026 14:56, Jochen Bandhauer wrote:
> 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
>
I created two patches for the doc update for REL_18_STABLE and master.

Regards
Jochen

--
Mit freundlichen Grüßen

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

Attachment Content-Type Size
v1-0001-doc-add-a-note-to-cluster-verbose_REL_18_STABLE.patch text/plain 1.2 KB
v1-0001-doc-add-a-note-to-repack-verbose_master.patch text/plain 1.1 KB
jb.vcf text/vcard 202 bytes

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Christophe Pettus 2026-08-31 21:34:23 Re: REPACK (CONCURRENTLY) doesn't handle invalid indexes
Previous Message Andrey Rachitskiy 2026-08-30 18:35:13 Re: BUG #19487: Error while executing SQL query involving XML parsing