Re: REINDEX CONCURRENTLY 2.0

On 02/17/2017 01:53 PM, Andreas Karlsson wrote:
> I am actually thinking about going the opposite direction (by reducing
> the number of times we call WaitForLockers), because it is not just
> about consuming transaction IDs, we also do not want to wait too many
> times for transactions to commit. I am leaning towards only calling
> WaitForLockersMultiple three times per table.
>
> 1. Between building and validating the new indexes.
> 2. Between setting the old indexes to invalid and setting them to dead
> 3. Between setting the old indexes to dead and dropping them
>
> Right now my patch loops over the indexes in step 2 and 3 and waits for
> lockers once per index. This seems rather wasteful.
>
> I have thought about that the code might be cleaner if we just looped
> over all indexes (and as a bonus the VERBOSE output would be more
> obvious), but I do not think it is worth waiting for lockers all those
> extra times.

Thinking about this makes me wonder about why you decided to use a
transaction per index in many of the steps rather than a transaction per
step. Most steps should be quick. The only steps I think the makes sense
to have a transaction per table are.

1) When building indexes to avoid long running transactions.

2) When validating the new indexes, also to avoid long running transactions.

But when swapping the indexes or when dropping the old indexes I do not
see any reason to not just use one transaction per step since we do not
even have to wait for any locks (other than WaitForLockers which we just
want to call once anyway since all indexes relate to the same table).

Andreas