Date: Wed, 2 Jan 2019 07:54:14 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	Sergei Kornilov <sk@zsrv.org>,
	Michael Paquier <michael.paquier@gmail.com>,
	Andreas Karlsson <andreas@proxel.se>,
	PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
	Craig Ringer <craig@2ndquadrant.com>
Subject: Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Message-ID: <20190102125414.GX2528@tamriel.snowman.net>
References: <20181214145222.GR3415@tamriel.snowman.net>
 <201812312116.pavh6ts5qeum@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="kUoBhQsr7LsiFken"
Content-Disposition: inline
In-Reply-To: <201812312116.pavh6ts5qeum@alvherre.pgsql>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--kUoBhQsr7LsiFken
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> On 2018-Dec-14, Stephen Frost wrote:
>=20
> > > My vote goes to put the keyword inside of and exclusively in the
> > > parenthesized option list.
> >=20
> > I disagree with the idea of exclusively having concurrently be in the
> > parentheses.  'explain buffers' is a much less frequently used option
> > (though that might, in part, be because it's a bit annoying to write out
> > explain (analyze, buffers) select...; I wonder if we could have a way to
> > say "if I'm running analyze, I always want buffers"...),
>=20
> I'm skeptical.  I think EXPLAIN ANALYZE is more common because it has
> more than one decade of advantage compared to the more detailed option
> list.  Yes, it's also easier, but IMO it's a brain thing (muscle
> memory), not a fingers thing.

I would argue that it's both.

> > but concurrently reindexing a table (or index..) is going to almost
> > certainly be extremely common, perhaps even more common than *not*
> > reindexing concurrently.
>=20
> Well, users can use the reindexdb utility and save some keystrokes.

That's a really poor argument as those unix utilities are hardly ever
used, in my experience.

> Anyway we don't typically add redundant ways to express the same things.
> Where we have them, it's just because the old way was there before, and
> we added the extensible way later.  Adding two in the first appearance
> of a new feature seems absurd to me.

SQL allows many, many different ways to express the same thing.  I agree
that we haven't done that much in our utility commands, but I don't see
that as an argument against doing so, just that we haven't (previously)
really had the need- because most of the time we don't have a bunch of
different options where we want to have a list.

> After looking at the proposed grammar again today and in danger of
> repeating myself, IMO allowing the concurrency keyword to appear outside
> the parens would be a mistake.  Valid commands:
>=20
>   REINDEX (VERBOSE, CONCURRENTLY) TABLE foo;
>   REINDEX (CONCURRENTLY) INDEX bar;

This discussion hasn't changed my opinion, and, though I'm likely
repeating myself as well, I also agree with the down-thread comment that
this ship really has already sailed.

Thanks!

Stephen

--kUoBhQsr7LsiFken
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJcLLR2AAoJEO1sijiDR2RVn4IP+wX7Z+YCYl3uffxEf0xJsdCl
9ufdCV3jJu+wxQiz+v3nRLXhgptcZ1Xk8hNNSQn4HTeb5kXq8HeR+zIc2hn9Wflz
aDhsZYdCcQ7xYvYu0LUdwRDwu5h7V5U1bUYq+afuXeG2NStR5VCtCuv33DRZEnB1
YwHZrcGPrYoTjcschYUPwfc2Wg+TxOpUYQuExU6WavPKZuXpPYODy+DW1Nj61aoF
2pO8IkPwCGQE80CtGcM6AnMkGr4hnHZ6HaJAfNpp010hkyLrJzkQkAUP9DX6Cnka
grrVLKn3IQIKUgCT8T6dwUtexMs3tBOR/c6XsbRkgKVolKN3CVtqL2RC7GkJLnGv
Ocz4FNwozSkMY2TzbnHI3ziurESF/GMb6NxTgpo5SMemjm0dpEHXTNYHbVmqr+QU
yWWZr0YRIZ7rHUuler4ijO4JpHPJSCcSlDnCuwdu94OfJN67zhjW2oU/8bqM/oNw
ft7gQ23nm/hqHr6tLnMT5STILJ/hTj0IS8O10QBilgNEgUBr/CphsZV/S7Na8Ntq
K10skVc90C1D2PJH49tOEK2MeggKgae+Vq9uszkbzjAxyiQYYnfqKBHyGzispn1C
JA4jsCWuyNELIP4zmrsIbm3uob0GRqKCOch/6KtZKj83lqDPr0DSSc4beYgD9wo/
jPFjmN2WBOll0SR0ig/X
=NaZ8
-----END PGP SIGNATURE-----

--kUoBhQsr7LsiFken--