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

Hey, what about wording

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

If clause `USING INDEX` is provided and the planner chooses a sequential
scan and sort, a temporary sort file is also needed, so the maximum space
requirement can reach twice the table size plus the index sizes. This
method is usually faster than an index scan, but if disk space is tight,
you might need to set `enable_sort` to `off` to force an index scan, or
omit `USING INDEX` if the table does not need to be reordered.

---

Radim

On Tue, 6 Oct 2026 at 22:05, Alvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:

> On 2026-Oct-06, Antonin Houska wrote:
>
> > I suspect there's a thinko in the "Notes on Resources" section.
> Shouldn't the
> > first paragraph start like this?
> >
> > "When the USING INDEX clause is given and an index scan is chosen, ..."
>
> Hmm, no -- this paragraph tries to explain what happens when we use the
> unsorted option, _or_ we use the sorted option but we use a indexscan to
> implement it. So either the VACUUM FULL, or the indexscan based
> CLUSTER. In this case we only have one extra copy of the table.
>
> The second paragraph tries to describe what happens when we use a
> seqscan and sort -- that is, we have USING INDEX, but we don't scan
> using that index (that is, CLUSTER that uses a sort). That requires
> additional storage (the tuplestore that is sorted).
>
> Maybe we need to reword both so that this is more obvious?
>
> > No objections regarding the "Notes on Concurrent Operation" section.
>
> Thanks for reading!
>
> --
> Álvaro Herrera Breisgau, Deutschland —
> https://www.EnterpriseDB.com/
> "I think my standards have lowered enough that now I think 'good design'
> is when the page doesn't irritate the living f*ck out of me." (JWZ)
>