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 1l41ST-0000zY-AD for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Jan 2021 12:59:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l41SP-0006uo-Ke for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Jan 2021 12:59:01 +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 1l41SP-0006uh-A8 for pgsql-hackers@lists.postgresql.org; Mon, 25 Jan 2021 12:59:01 +0000 Received: from mail-io1-xd36.google.com ([2607:f8b0:4864:20::d36]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1l41SI-0002c5-4L for pgsql-hackers@lists.postgresql.org; Mon, 25 Jan 2021 12:59:00 +0000 Received: by mail-io1-xd36.google.com with SMTP id q129so26259782iod.0 for ; Mon, 25 Jan 2021 04:58:53 -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=MnmPCfKXH5gj5dY4qACQjezad0Tor7XyP3lv2sUj3G4=; b=F3dmWI9078f3BZuwA+cWo/SYIGIcT4Nmz3jCktwk/tiuVerluKPMBMPG5aJHM/O3gq 8yTI9mgZopGYwy/V6clH5kBgeGrxs0fumEk+tjdMUOe8IceWZeRh73H2RW6MYm0uIBWS Y8wKrlZtjd7umEQxFmgEGzEa/HQ4S/i6pvUR11jG11OvDn1PsY4LduM5cWH+x8iiNSbt zJb3Yvz2NEC/9wBPNMznwFHmYvaZTsjYWk/AKinSp/Kd8ww4VbiGZPuNXyOmwopVeMdr ykBO894ikBF94OrsgF911amoiDK49bDdkTkxxfaDnADpqYqDZhTBo3rX5Wq6472KR+mt bJiA== 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=MnmPCfKXH5gj5dY4qACQjezad0Tor7XyP3lv2sUj3G4=; b=F5Afatl3+WybWn4YZ4vDRRP/WLcUAtdHBqp7OgvH84DE8idkk4sWLOQmIzkun3tY/q 5M5MMWtk1tEfYMBwRyjOVArVWeHAc02iYX8BvtMaXsD2CPxM4cbqVYb9TuCtVlDBaXZn RNodDR9sDj5pxDpoemKlZcO1Vnrh1AVeRZYozloAHVJvcPtue0cyCfo5DNtDRLEmewCZ TkDhvGLsH3kxUndU3IttaJma4uytKRTqddqRs7g7R5uE6K7D7Ir1ylmEfGC57NNtmJNJ 74w1NHaajFFYaG3LX38/eG7CCAgPQOVwIF/wHcf/Mrmbjdxe+3S0PWmrEPdhYL/9n20h +uYw== X-Gm-Message-State: AOAM532XlPrGm/sfwg4gGdNVLZLlfD0kLse9vUG7Qto0D9a+/HqVjNNS Qsnu5TVMKq/ZMbpHQQRSLW7S+A== X-Google-Smtp-Source: ABdhPJxhfJaO3+KgxB1Bro2S6WHiVEfoPZwzFjdpQvSsN/auwOtErDBBxh9Z3SC1jMS1XM7fWCfKTQ== X-Received: by 2002:a05:6e02:1608:: with SMTP id t8mr140278ilu.79.1611579533368; Mon, 25 Jan 2021 04:58:53 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id q5sm11398203ilg.62.2021.01.25.04.58.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jan 2021 04:58:52 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 13D7480140D; Mon, 25 Jan 2021 06:58:50 -0600 (CST) Date: Mon, 25 Jan 2021 06:58:49 -0600 From: Justin Pryzby To: Michael Paquier Cc: Alexey Kondratov , 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 Message-ID: <20210125125849.GA30745@telsasoft.com> References: <03f88f70618ce73e75837b6125a143f7@postgrespro.ru> <20210120183439.GA21339@alvherre.pgsql> <20210121212651.GY8560@telsasoft.com> <944df7cc452fe0c34cf7820da4588d05@postgrespro.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Jan 25, 2021 at 05:07:29PM +0900, Michael Paquier wrote: > On Fri, Jan 22, 2021 at 05:07:02PM +0300, Alexey Kondratov wrote: > > I have updated patches accordingly and also simplified tablespaceOid checks > > and assignment in the newly added SetRelTableSpace(). Result is attached as > > two separate patches for an ease of review, but no objections to merge them > > and apply at once if everything is fine. ... > +SELECT relname FROM pg_class > +WHERE reltablespace=(SELECT oid FROM pg_tablespace WHERE spcname='regress_tblspace'); > [...] > +-- first, check a no-op case > +REINDEX (TABLESPACE pg_default) INDEX regress_tblspace_test_tbl_idx; > +REINDEX (TABLESPACE pg_default) TABLE regress_tblspace_test_tbl; > Reindexing means that the relfilenodes are changed, so the tests > should track the original and new relfilenodes and compare them, no? > In short, this set of regression tests does not make sure that a > REINDEX actually happens or not, and this may read as a reindex not > happening at all for those tests. For single units, these could be > saved in a variable and compared afterwards. create_index.sql does > that a bit with REINDEX SCHEMA for a set of relations. You might also check my "CLUSTER partitioned" patch for another way to do that. https://www.postgresql.org/message-id/20210118183459.GJ8560%40telsasoft.com https://www.postgresql.org/message-id/attachment/118126/v6-0002-Implement-CLUSTER-of-partitioned-table.patch -- Justin