| 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 |
| 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 |