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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
