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 1ksCWb-0003Mr-2S for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Dec 2020 22:22:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ksCWX-00029D-Op for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Dec 2020 22:22:25 +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 1ksCWW-000296-Ok for pgsql-hackers@lists.postgresql.org; Wed, 23 Dec 2020 22:22:25 +0000 Received: from [66.111.4.224] (helo=new2-smtp.messagingengine.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ksCWU-0007TL-2u for pgsql-hackers@lists.postgresql.org; Wed, 23 Dec 2020 22:22:23 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id A3F9B580309; Wed, 23 Dec 2020 17:22:10 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 23 Dec 2020 17:22:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=FklJNsx9N0rwNclPn F71oADEvT4Ipl0J1W7UFIfJeoM=; b=MECw9uBwi3vEcecZICqw+hNq7FX+64OAn taZP5Spqr5saDqC9dOfIEqG863hXVViTpWXbaae6fsqLjIM7hoJSg4MyYonslDac jpo7d49ZYmCoj0x3OTg4dImxqamxCWMTEsAM+BGacsNWP5Dzh2KfUkwno63xu5Yf DkHCpzgUB9CKhe2BXBA6xLxOqPnzB4SlzK8kO77DC2OrNuIuu70bSpUl9dOxjEPi a52zQ4sO9QeVrbNop2VDwrERZx7TAC3qDnhHiuhDdAbwvVc01QKGk2sGRgFdnsup BYNH0OvDsrY+aPoW6+8/uVbe17hM3Yk8fr0P+z+nv52NtmorLY9KQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddtjedgudeitdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkgggtuggjfgesthdtredttdervdenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepvefgleevgeeujeeghfegteeghfegheeifeehheelteet ieduieeihffggfehffetnecukfhppeduledtrdelhedrudekrdejleenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghl vhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.18.79]) by mail.messagingengine.com (Postfix) with ESMTPA id 20A71240057; Wed, 23 Dec 2020 17:22:08 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 3BD652A0FF3; Wed, 23 Dec 2020 19:22:05 -0300 (-03) Date: Wed, 23 Dec 2020 19:22:05 -0300 From: Alvaro Herrera To: Michael Paquier Cc: Justin Pryzby , Peter Eisentraut , 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: <20201223222205.GA13552@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Host-Lookup-Failed: Reverse DNS lookup failed for 66.111.4.224 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Dec-23, Michael Paquier wrote: > bool > -reindex_relation(Oid relid, int flags, int options) > +reindex_relation(Oid relid, int flags, ReindexOptions *options) > { > Relation rel; > Oid toast_relid; Wait a minute. reindex_relation has 'flags' and *also* 'options' with an embedded 'flags' member? Surely that's not right. I see that they carry orthogonal sets of options ... but why aren't they a single bitmask instead of two separate ones? This looks weird and confusing. Also: it seems a bit weird to me to put the flags inside the options struct. I would keep them separate -- so initially the options struct would only have the tablespace OID, on API cleanliness grounds: struct ReindexOptions { tablepaceOid oid; }; extern bool reindex_relation(Oid relid, bits32 flags, ReindexOptions *options); I guess you could argue that it's more performance to set up only two arguments to the function call instead of three .. but I doubt that's measurable for anything in DDL-land. But also, are we really envisioning that these routines would have all that many additional options? Maybe it is sufficient to do just extern bool reindex_relation(Oid relid, bits32 flags, tablespaceOid Oid);