Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Steve Singer <steve(at)ssinger(dot)info>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Jose Luis Tallon <jltallon(at)adv-solutions(dot)net>
Subject: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly
Date: 2020-08-11 05:39:45
Message-ID: 20200811053945.GG17986@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Aug 09, 2020 at 09:24:43PM -0500, Justin Pryzby wrote:
> That part of your patch handles REINDEX and REINDEX(*) differently than mine.
> Yours is technically more correct/complete. But, I recall Tom objected a
> different patch because of completing to a single char. I think the case is
> arguable either way: if only some completions are shown, then it hides the
> others..
> https://www.postgresql.org/message-id/14255.1536781029@sss.pgh.pa.us

Thanks for the reference. Indeed, I can see this argument going both
ways. Now showing "(" after typing REINDEX as a completion option
does not let the user know that parenthesized options are supported,
but on the contrary this can also clutter the output. The latter
makes more sense now to be consistent with VACUUM and ANALYZE though,
so I have removed that part, and applied the patch.

> The rest of your patch looks fine. In my mind, REINDEX(CONCURRENTLY) was the
> "new way" to write things, and it's what's easy to support, so I think I didn't
> put special effort into making tab completion itself complete.

The grammar that has been committed was the one that for the most
support, so we need to live with that. I wonder if we should simplify
ReindexStmt and move the "concurrent" flag to be under "options", but
that may not be worth the time spent on as long as we don't have
CONCURRENTLY part of the parenthesized grammar.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-08-11 05:44:22 Re: Hybrid Hash/Nested Loop joins and caching results from subplans
Previous Message David Rowley 2020-08-11 05:23:42 Re: Hybrid Hash/Nested Loop joins and caching results from subplans