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 6605.1791358498@localhost
Whole thread
In response to Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes  (Alvaro Herrera <alvherre@kurilemu.de>)
Responses Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes
List pgsql-hackers
Alvaro Herrera <alvherre@kurilemu.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.

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.

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



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Parallel Apply
Next
From: Fujii Masao
Date:
Subject: Re: [PATCH] psql: avoid CREATE command completion after GRANT/REVOKE CREATE