Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes - Mailing list pgsql-hackers

From Antonin Houska
Subject Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes
Date
Msg-id 30341.1791373711@localhost
Whole thread
In response to Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes  (Alvaro Herrera <alvherre@kurilemu.de>)
List pgsql-hackers
Alvaro Herrera <alvherre@kurilemu.de> wrote:

> On 2026-Oct-07, Antonin Houska wrote:
> 
> > ok. What I find disturbing in the first sentence is the "but" conjunction:
> > 
> > "... that clause is given but an index scan is chosen ..."
> > 
> > Shouldn't it rater be "and"?
> > 
> > When I read "but", I usually expect a contradiction. However I see no
> > contradiction between specifying the USING INDEX clause and choosing index
> > scan.
> 
> You're right, that was pretty hard to read.  How about this, following
> Radim's suggestion?
> 
>    <para>
>     <command>REPACK</command> creates a temporary copy of the table and all
>     of its indexes, so you need free disk space at least equal to the sum
>     of the table size and the index sizes.
>    </para>
> 
>    <para>
>     If the <literal>USING INDEX</literal> clause is given and the planner
>     chooses a sequential scan and sort to implement it, a temporary sort
>     file that uses the table size again is needed in addition to the above.
>     This method is usually faster than an index scan, but if the disk space
>     requirement is intolerable, you can disable this choice by temporarily
>     setting <xref linkend="guc-enable-sort"/> to <literal>off</literal>; or
>     omitting <literal>USING INDEX</literal> if the table doesn't need to be
>     reordered.
>    </para>

Yes, this looks well structured - first the simple case, then the "less
simple".

> The "... that uses the table size again is needed ..." bit looks
> somewhat odd to me, but I don't know how to make it better.

The only variant that occurs to me is

"... that creates one more copy of the table ..."

Just in case.

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: PG19: two RI fast-path issues found while testing the batching revert
Next
From: Fujii Masao
Date:
Subject: Re: [PATCH] psql: avoid CREATE command completion after GRANT/REVOKE CREATE