From: Stephen Frost <sfrost@snowman.net>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Sergei Kornilov <sk@zsrv.org>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Andreas Karlsson <andreas@proxel.se>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Cc: Craig Ringer <craig@2ndquadrant.com>
Subject: Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Date: Wed, 2 Jan 2019 07:54:14 -0500
Message-ID: <20190102125414.GX2528@tamriel.snowman.net> (raw)
In-Reply-To: <201812312116.pavh6ts5qeum@alvherre.pgsql>
References: <20181214145222.GR3415@tamriel.snowman.net>
<201812312116.pavh6ts5qeum@alvherre.pgsql>
Greetings,
* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> On 2018-Dec-14, Stephen Frost wrote:
>
> > > My vote goes to put the keyword inside of and exclusively in the
> > > parenthesized option list.
> >
> > 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"...),
>
> 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.
>
> 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:
>
> 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
Attachments:
[application/pgp-signature] signature.asc (818B, ../20190102125414.GX2528@tamriel.snowman.net/2-signature.asc)
download
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: sfrost@snowman.net, alvherre@2ndquadrant.com, peter.eisentraut@2ndquadrant.com, sk@zsrv.org, michael.paquier@gmail.com, andreas@proxel.se, craig@2ndquadrant.com
Subject: Re: [HACKERS] REINDEX CONCURRENTLY 2.0
In-Reply-To: <20190102125414.GX2528@tamriel.snowman.net>
* 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