Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j1Yig-00043p-Dz for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Feb 2020 16:49:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j1Yif-0006J6-0Y for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Feb 2020 16:49:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j1Yie-0006Ib-K7 for pgsql-hackers@lists.postgresql.org; Tue, 11 Feb 2020 16:49:04 +0000 Received: from mail-yb1-xb42.google.com ([2607:f8b0:4864:20::b42]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j1YiT-0008Dq-1L for pgsql-hackers@lists.postgresql.org; Tue, 11 Feb 2020 16:49:00 +0000 Received: by mail-yb1-xb42.google.com with SMTP id k69so5679818ybk.4 for ; Tue, 11 Feb 2020 08:48:52 -0800 (PST) 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=sniRiu7TyPm6BFbhjaI5Xi5repbBoWC/HAwKSc3AKJs=; b=Evh/51e0h4QIu4zAgncE/QA+tLsm9sIwt3lTpL1kajL75CTlpKGDjnp7sz6eOw87xF eMbTvIGNpTJI90aKN/iZ9z9FAnfJJj4otVZXFIResSp5pJU4NBflQ3LGR/0+sEHHvOBH vPC8BPsh5HwbCp/VvlZrqo+gmSGcXcI0LyX0YVt2qIWfhgSivGteb1Z2CmAYneYfMt63 KgNyxGNPqRNljVpD0tg7XQeX4RUgLWiPmwNKtGnrDFy0WH3pSnZJ8PaG+g4ZtehJIgwG /226Iadch2xjLG5pqNtzqq+0op7GhpPM7UgsgXgzp5zpWMAYFkpPFTOKHPnG34CiePXt MjLg== 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=sniRiu7TyPm6BFbhjaI5Xi5repbBoWC/HAwKSc3AKJs=; b=kEuwMztpRA7ZN08Dc+L6/0Jwcdrb2d6Pk3U62KDgfqja2lHWQfdxfxng8YvvyOkTMY 814rF1BH8AzE2B6Wjx2zyKNSijSgb+TFcG678YlAOaJphKl57FD6Quyy+L0/ChVJUl3U vvfdkcwOyk/0p684HJ6zNAzeuAOMMxMjoHkLBDPsaNPi35rZ1rmxeDMh0fA8gRnxlIfF t59cLVMekMU40YGAuL4W1s+BjS8s++KtnQ5eDg5UT4Dy0/mLeYYPRtgNWblBk2eLlsMx nT7W1xiVfk7ASNp++NLkbbWdn2tw0ZIIi3fCcrqst8nPsH06F2ETZR/8DjjTLxhsrMFk ujog== X-Gm-Message-State: APjAAAVMH+LRBNzLhguick10cDkZE8CiJkGb3+QnZAsYuPHM53zDs/3l e9Ofpcdte/wYKxm2CENtPJa3xw== X-Google-Smtp-Source: APXvYqwhLn450cVjXUp4Gw2jMY4iW/ejxpJI9FpOm6nZ2PBMhtElbd99EDJYstrbM7+dk8AhS2+KzQ== X-Received: by 2002:a25:d646:: with SMTP id n67mr6414468ybg.87.1581439731187; Tue, 11 Feb 2020 08:48:51 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id l5sm2009120ywd.48.2020.02.11.08.48.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Feb 2020 08:48:50 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id C6575800926; Tue, 11 Feb 2020 10:48:48 -0600 (CST) Date: Tue, 11 Feb 2020 10:48:48 -0600 From: Justin Pryzby To: Alexey Kondratov 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 Message-ID: <20200211164848.GO1412@telsasoft.com> References: <8a8f5f73-00d3-55f8-7583-1375ca8f6a91@postgrespro.ru> <157395200750.29912.1178609357962324139.pgcf@coridan.postgresql.org> <827a9139-e02b-2dbf-5c6c-a6fbcaa1739a@postgrespro.ru> <20191127035416.GG5435@paquier.xyz> <3ae48673-283c-3e99-3dd8-36ebb81614b5@postgrespro.ru> <20191202082134.GI1696@paquier.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk For your v7 patch, which handles REINDEX to a new tablespace, I have a few minor comments: + * the relation will be rebuilt. If InvalidOid is used, the default => should say "currrent", not default ? +++ b/doc/src/sgml/ref/reindex.sgml + TABLESPACE ... + new_tablespace => I saw you split the description of TABLESPACE from new_tablespace based on comment earlier in the thread, but I suggest that the descriptions for these should be merged, like: + + TABLESPACEnew_tablespace + + + Allow specification of a tablespace where all rebuilt indexes will be created. + Cannot be used with "mapped" relations. If SCHEMA, + DATABASE or SYSTEM are specified, then + all unsuitable relations will be skipped and a single WARNING + will be generated. + + + The existing patch is very natural, especially the parts in the original patch handling vacuum full and cluster. Those were removed to concentrate on REINDEX, and based on comments that it might be nice if ALTER handled CLUSTER and VACUUM FULL. On a separate thread, I brought up the idea of ALTER using clustered order. Tom pointed out some issues with my implementation, but didn't like the idea, either. So I suggest to re-include the CLUSTER/VAC FULL parts as a separate 0002 patch, the same way they were originally implemented. BTW, I think if "ALTER" were updated to support REINDEX (to allow multiple operations at once), it might be either: |ALTER INDEX i SET TABLESPACE , REINDEX -- to reindex a single index on a given tlbspc or |ALTER TABLE tbl REINDEX USING INDEX TABLESPACE spc; -- to reindex all inds on table inds moved to a given tblspc "USING INDEX TABLESPACE" is already used for ALTER..ADD column/table CONSTRAINT. -- Justin