From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
Subject: | Re: [HACKERS] REINDEX CONCURRENTLY 2.0 |
Date: | 2019-01-02 12:54:14 |
Message-ID: | 20190102125414.GX2528@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Alvaro Herrera (alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2019-01-02 13:16:42 | Re: Is MinMaxExpr really leakproof? |
Previous Message | Surafel Temesgen | 2019-01-02 12:50:24 | Re: pg_dump multi VALUES INSERT |