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 1kG29E-0004C2-UG for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Sep 2020 15:36:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kG29D-00041i-Sh for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Sep 2020 15:36:35 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kG29D-00041b-Mf for pgsql-hackers@lists.postgresql.org; Wed, 09 Sep 2020 15:36:35 +0000 Received: from mail-il1-x141.google.com ([2607:f8b0:4864:20::141]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kG29B-0004W3-3M for pgsql-hackers@lists.postgresql.org; Wed, 09 Sep 2020 15:36:34 +0000 Received: by mail-il1-x141.google.com with SMTP id t18so2125521ilp.5 for ; Wed, 09 Sep 2020 08:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=SOSgjuUFe3WbjJAq9z4n367vNpjoJUcG+oYbVeGamkU=; b=E0Q0e4CwukXkQp3KCkkWqMPT+VJZi6Pr2ctpTpHikB7ckpfEJj52sb0VgFTbCeMmQj qJmbI778XNbGMDP6rAoxeSADcCef9V3ik5igrpM0IUGh9tUdMpEpkichaThMdFHZAAve sPjvBV9F3nr7eeADuGZQS1Ok3IeoOUjgULpHjzVOpi8X5PD5J7ABkrEObFfYGxQMQqKe j8GDAfcQHRtkiPjbRHbvyfWMHtolW37jz6k8X/B63ZQKpn8Ha0cLKZQ0S0X9gZ13BlAC HrnyWJp3z1yMq2FcQpB15DBiMVXtWJJNc58qoXrJ4MUjuRMGtpGvgJvFl7IR301bB/vK pLwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=SOSgjuUFe3WbjJAq9z4n367vNpjoJUcG+oYbVeGamkU=; b=f4UlFWLwE2YNlOevmDhlGzrKCdkXBavmTWwjzDZtSxTDQA77rjryFed7chZANxorKW 4DNA09u97RJEGqh468uIFcLGaSNnQqurlSdZPy68TEZ8VJoGsa8P//dmWZtALfB47bwW NU3mtxyhT+lFvy8DeCOIU0SCcu+YdjkPB6M/QiwWo8cgaQhEKoRG8CYIb0ve7sSvYIQl GUxVbzngPSfyn7PtPNxqTGw7aKL3l8PN5k5O5mslv0mlj5qk2aRwdKZLl+rZAOmb9jMO DyrRyuIAjQj+q9NU77CbTqH45Mtt1To7b+myBG9vfiPwP4fQUKF+iOotwxp4w4FV8VQW YENw== X-Gm-Message-State: AOAM531UkLXH0E+oV8A6FA/H2W3D40qMarBt+jqfF/W4GQsaqT84je/H uwPIFzt1B7SFIe4tn1PN2POypg== X-Google-Smtp-Source: ABdhPJy4htsLg0YPp6tFKFfwPGfQJpC+ZtvcxALLSkX0txsc+8XKypd8sb/BUThR6+yq1FNIY30vbA== X-Received: by 2002:a92:4001:: with SMTP id n1mr4235208ila.69.1599665792299; Wed, 09 Sep 2020 08:36:32 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id u25sm1312931iot.35.2020.09.09.08.36.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Sep 2020 08:36:31 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id AC0F1800747; Wed, 9 Sep 2020 10:36:29 -0500 (CDT) Date: Wed, 9 Sep 2020 10:36:29 -0500 From: Justin Pryzby To: Michael Paquier Cc: Alvaro Herrera , Alexey Kondratov , Masahiko Sawada , Steve Singer , pgsql-hackers@lists.postgresql.org, Robert Haas , Alexander Korotkov , Masahiko Sawada , Jose Luis Tallon Subject: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly Message-ID: <20200909153629.GG18552@telsasoft.com> References: <20200908233951.GC18552@telsasoft.com> <20200909000238.GA1563@alvherre.pgsql> <20200909001757.GD18552@telsasoft.com> <20200909122200.GA2743@paquier.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200909122200.GA2743@paquier.xyz> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Sep 09, 2020 at 09:22:00PM +0900, Michael Paquier wrote: > On Tue, Sep 08, 2020 at 07:17:58PM -0500, Justin Pryzby wrote: > > Initially I added List *params, and Michael suggested to retire > > ReindexStmt->concurrent. I provided a patch to do so, initially by leaving int > > options and then, after this, removing it to "complete the thought", and get > > rid of the remnants of the "old way" of doing it. This is also how vacuum and > > explain are done. > > https://www.postgresql.org/message-id/20200902022410.GA20149%40telsasoft.com > > Defining a set of DefElem when parsing and then using the int > "options" with bitmasks where necessary at the beginning of the > execution looks like a good balance to me. This way, you can extend > the grammar to use things like (verbose = true), etc. It doesn't need to be extended - defGetBoolean already handles that. I don't see what good can come from storing the information in two places in the same structure. |postgres=# CLUSTER (VERBOSE on) pg_attribute USING pg_attribute_relid_attnum_index ; |INFO: clustering "pg_catalog.pg_attribute" using index scan on "pg_attribute_relid_attnum_index" |INFO: "pg_attribute": found 0 removable, 2968 nonremovable row versions in 55 pages |DETAIL: 0 dead row versions cannot be removed yet. |CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s. |CLUSTER -- Justin