On Tue, Feb 28, 2017 at 5:29 AM, Bruce Momjian <br...@momjian.us> wrote: > On Fri, Feb 17, 2017 at 11:05:31PM +0900, Michael Paquier wrote: >> 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. > > FYI, the thread started on 2013-11-15.
I don't object to the addition of this patch in next CF as this presents no new concept. Still per the complications this patch and because it is a complicated patch I was wondering if people are fine to include it in this last CF. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
