pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Bruce Momjian <bruce@momjian.us>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Andreas Karlsson <andreas@proxel.se>
Cc: Andres Freund <andres@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: Jim Nasby <jim@nasby.net>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: REINDEX CONCURRENTLY 2.0
Date: Mon, 27 Feb 2017 15:29:16 -0500
Message-ID: <20170227202916.GC421@momjian.us> (raw)
In-Reply-To: <CAB7nPqRRtOgKm1Ztw2kNbTAxnBxScHDdy1v35z__ju4GwDFnFw@mail.gmail.com>
References: <CA+TgmoZtd=sa8LD0tnWgRDzx-Zzt_g_FnPf9jtj61z_rbuse6w@mail.gmail.com>
	<CA+TgmoZ=0NMfMVjemYjO0zWFi8PS3OMZCEsqimcgc34U8UKQeg@mail.gmail.com>
	<20150202141014.GA9201@alap3.anarazel.de>
	<4b6b0b72-94c8-79ad-baf1-b01587807315@proxel.se>
	<CAB7nPqRZR-Wf-Z6XfRcv3NRUpC0rGofea538XtOWNzC3R_cTFg@mail.gmail.com>
	<68cd9337-90ab-c654-ed6b-a32abc26e147@proxel.se>
	<CAB7nPqSARzEpj__y7bMCu3w_YgfM9Jc=wu=wHLu6ZLkgq2OMXg@mail.gmail.com>
	<1da61300-31e8-d416-1d41-56c15cd4753d@proxel.se>
	<083ea668-538e-06ae-c1a7-37b0edbeeb9c@proxel.se>
	<CAB7nPqRRtOgKm1Ztw2kNbTAxnBxScHDdy1v35z__ju4GwDFnFw@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

On Fri, Feb 17, 2017 at 11:05:31PM +0900, Michael Paquier wrote:
> On Fri, Feb 17, 2017 at 10:43 PM, Andreas Karlsson <andreas@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  <bruce@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



view thread (170+ messages)  latest in thread

Message-ID: <20170227202916.GC421@momjian.us>
Permalink:  ../20170227202916.GC421@momjian.us/
Also on:    postgresql.org/message-id/20170227202916.GC421@momjian.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: bruce@momjian.us, michael.paquier@gmail.com, andreas@proxel.se, andres@2ndquadrant.com, robertmhaas@gmail.com, peter_e@gmx.net, jim@nasby.net
  Subject: Re: REINDEX CONCURRENTLY 2.0
  In-Reply-To: <20170227202916.GC421@momjian.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox