On Fri, Feb 17, 2017 at 10:43 PM, Andreas Karlsson <andr...@proxel.se> wrote: > 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.
I don't recall all the details to be honest :) > 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). Perhaps, this really needs a careful lookup. By the way, as this patch is showing up for the first time in this development cycle, would it be allowed in the last commit fest? That's not a patch in the easy category, far from that, but it does not present a new concept. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
