Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes

Alvaro Herrera <alvherre(at)kurilemu(dot)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