Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jIyk4-0001AM-Fg for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Mar 2020 18:02:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jIyk3-0001bG-DA for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Mar 2020 18:02:31 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jIyk3-0001b9-2P for pgsql-hackers@lists.postgresql.org; Mon, 30 Mar 2020 18:02:31 +0000 Received: from cyclops.postgrespro.ru ([93.174.131.138] helo=mail.postgrespro.ru) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jIyjz-0000Ev-Uz for pgsql-hackers@lists.postgresql.org; Mon, 30 Mar 2020 18:02:30 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 66FEF21C5703; Mon, 30 Mar 2020 21:02:24 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from mail.postgrespro.ru (cyclops.l.postgrespro.ru [192.168.27.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 24A6A21C56D5; Mon, 30 Mar 2020 21:02:23 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1585591343; bh=IaikIcVpMPdbb1r59CjTpqJqjYSsVghig9Crd59JdQk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=k2P1Iw9cvyqnIpoKj984Ek4gzQL1p2WSwjPCWV7Fywh0FQVcN/E5hwxzuHX+mqTwv 4lR06JdhRejMUa93n7o8TMXWgQ4TvlSvW+w/JCGDYREfUOF8s46KE3Gz+MSPAecnHg x0W/nmj8NKM1XCIK1mzsjb7B0Uhg5oWQ2wMDUhm4= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 30 Mar 2020 21:02:22 +0300 From: Alexey Kondratov To: Justin Pryzby Cc: Michael Paquier , Masahiko Sawada , Steve Singer , pgsql-hackers@lists.postgresql.org, Alvaro Herrera , Robert Haas , Alexander Korotkov , Masahiko Sawada , Jose Luis Tallon Subject: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly In-Reply-To: <20200328001112.GX20103@telsasoft.com> References: <20200211164848.GO1412@telsasoft.com> <20200229145304.GI29456@telsasoft.com> <20200309200447.GA32459@telsasoft.com> <20200325234027.GH21443@telsasoft.com> <39a055a7a8cd19552f35f4cb98a8cd80@postgrespro.ru> <20200326180112.GH17431@telsasoft.com> <20200327040106.GC20103@telsasoft.com> <20200328001112.GX20103@telsasoft.com> User-Agent: Roundcube Webmail/1.4.0 Message-ID: X-Sender: a.kondratov@postgrespro.ru List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-03-28 03:11, Justin Pryzby wrote: > On Thu, Mar 26, 2020 at 11:01:06PM -0500, Justin Pryzby wrote: >> > Another issue is this: >> > > +VACUUM ( FULL [, ...] ) [ TABLESPACE new_tablespace ] [ table_and_columns [, ...] ] >> > As you mentioned in your v1 patch, in the other cases, "tablespace >> > [tablespace]" is added at the end of the command rather than in the middle. I >> > wasn't able to make that work, maybe because "tablespace" isn't a fully >> > reserved word (?). I didn't try with "SET TABLESPACE", although I understand >> > it'd be better without "SET". > SET does not change anything in my experience. The problem is that opt_vacuum_relation_list is... optional and TABLESPACE is not a fully reserved word (why?) as you correctly noted. I have managed to put TABLESPACE to the end, but with vacuum_relation_list, like: | VACUUM opt_full opt_freeze opt_verbose opt_analyze vacuum_relation_list TABLESPACE name | VACUUM '(' vac_analyze_option_list ')' vacuum_relation_list TABLESPACE name It means that one would not be able to do VACUUM FULL of the entire database + TABLESPACE change. I do not think that it is a common scenario, but this limitation would be very annoying, wouldn't it? > >> >> I think we should use the parenthesized syntax for vacuum - it seems >> clear in >> hindsight. >> >> Possibly REINDEX should use that, too, instead of adding OptTablespace >> at the >> end. I'm not sure. > > The attached mostly implements generic parenthesized options to > REINDEX(...), > so I'm soliciting opinions: should TABLESPACE be implemented in > parenthesized > syntax or non? > >> CLUSTER doesn't support parenthesized syntax, but .. maybe it should? > > And this ? > Hmm, I went through the well known to me SQL commands in Postgres and a bit more. Parenthesized options list is mostly used in two common cases: - In the beginning for boolean options only, e.g. VACUUM - In the end for options of a various type, but accompanied by WITH, e.g. COPY, CREATE SUBSCRIPTION Moreover, TABLESPACE is already used in CREATE TABLE/INDEX in the same way I did in 0001-0002. That way, putting TABLESPACE option into the parenthesized options list does not look to be convenient and semantically correct, so I do not like it. Maybe others will have a different opinion. Putting it into the WITH (...) options list looks like an option to me. However, doing it only for VACUUM will ruin the consistency, while doing it for CLUSTER and REINDEX is not necessary, so I do not like it either. To summarize, currently I see only 2 + 1 extra options: 1) Keep everything with syntax as it is in 0001-0002 2) Implement tail syntax for VACUUM, but with limitation for VACUUM FULL of the entire database + TABLESPACE change 3) Change TABLESPACE to a fully reserved word Regards -- Alexey Kondratov Postgres Professional https://www.postgrespro.com Russian Postgres Company