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 1ks6kK-0007sX-Bx for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Dec 2020 16:12:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ks6kJ-0000SU-AG for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Dec 2020 16:12:15 +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 1ks6kJ-0000SM-1k for pgsql-hackers@lists.postgresql.org; Wed, 23 Dec 2020 16:12:15 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ks6kG-0007xx-Hi for pgsql-hackers@lists.postgresql.org; Wed, 23 Dec 2020 16:12:14 +0000 Received: from mail.postgrespro.ru (cyclops.postgrespro.ru [93.174.131.138]) (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 49AE921C7D31; Wed, 23 Dec 2020 19:12:11 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1608739931; bh=OUDJAtNRlq31ojU4mnzdXuxd8ln/oU0D7IN1IOYuuVU=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=W1//g5Hn3AvUYxyyksmhbmd82pMI/sIpLso+Bu+gaSiFbGoREDyWi6+OP3z/beCrx 2VG2GSuAhu3NIRHaF/DqGuezrOIHuoyYPRdgJlMqbaUAA5aEqGqAdBHurcuiKKGip6 zFCssqGNopjTQKxSU2Kc/An7Ozm0BFb/LqWrnMRs= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 23 Dec 2020 19:12:11 +0300 From: Alexey Kondratov To: Justin Pryzby Cc: Zhihong Yu , Michael Paquier , Alvaro Herrera , Peter Eisentraut , 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 In-Reply-To: <20201223052200.GP30237@telsasoft.com> References: <7ec67c56-2377-cd05-51a0-691104404abe@enterprisedb.com> <20201216004517.GA18498@alvherre.pgsql> <20201222083204.GL30237@telsasoft.com> <20201222211537.GO30237@telsasoft.com> <20201223052200.GP30237@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-12-23 08:22, Justin Pryzby wrote: > On Tue, Dec 22, 2020 at 03:22:19PM -0800, Zhihong Yu wrote: >> Justin: >> For reindex_index() : >> >> + if (options->tablespaceOid == MyDatabaseTableSpace) >> + options->tablespaceOid = InvalidOid; >> ... >> + oldTablespaceOid = iRel->rd_rel->reltablespace; >> + if (set_tablespace && >> + (options->tablespaceOid != oldTablespaceOid || >> + (options->tablespaceOid == MyDatabaseTableSpace && >> OidIsValid(oldTablespaceOid)))) >> >> I wonder why the options->tablespaceOid == MyDatabaseTableSpace clause >> appears again in the second if statement. >> Since the first if statement would assign InvalidOid >> to options->tablespaceOid when the first if condition is satisfied. > > Good question. Alexey mentioned on Sept 23 that he added the first > stanza. to > avoid storing the DB's tablespace OID (rather than InvalidOid). > > I think the 2nd half of the "or" is unnecessary since that was added > setting to > options->tablespaceOid = InvalidOid. > If requesting to move to the DB's default tablespace, it'll now hit the > first > part of the OR: > >> + (options->tablespaceOid != oldTablespaceOid || > > Without the first stanza setting, it would've hit the 2nd condition: > >> + (options->tablespaceOid == MyDatabaseTableSpace && >> OidIsValid(oldTablespaceOid)))) > > which means: "user requested to move a table to the DB's default > tblspace, and > it was previously on a nondefault space". > > So I think we can drop the 2nd half of the OR. Thanks for noticing. Yes, I have not noticed that we would have already assigned tablespaceOid to InvalidOid in this case. Back to the v7 we were doing this assignment a bit later, so this could make sense, but now it seems to be redundant. For some reason I have mixed these refactorings separated by a dozen of versions... Thanks -- Alexey Kondratov Postgres Professional https://www.postgrespro.com Russian Postgres Company