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. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
