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

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>

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.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Are you not unsure you want to delete Firefox?
[Not unsure] [Not not unsure] [Cancel]
http://smylers.hates-software.com/2008/01/03/566e45b2.html