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 1nZvVx-0008Sw-JG for pgsql-hackers@arkaria.postgresql.org; Thu, 31 Mar 2022 14:11: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 1nZvVw-0006SB-Fd for pgsql-hackers@arkaria.postgresql.org; Thu, 31 Mar 2022 14:11:04 +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 1nZvVw-0006RI-3B for pgsql-hackers@lists.postgresql.org; Thu, 31 Mar 2022 14:11:04 +0000 Received: from mail-il1-x131.google.com ([2607:f8b0:4864:20::131]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nZvVo-0003jj-9K for pgsql-hackers@lists.postgresql.org; Thu, 31 Mar 2022 14:11:00 +0000 Received: by mail-il1-x131.google.com with SMTP id t15so188519ilq.12 for ; Thu, 31 Mar 2022 07:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=J0fZ/hfWBt0zaKTmGjpMPgZQc3JrPhDmsIB0zs3wpDo=; b=5JYgmdrFII+j4CkPZJ+U8keGHQX8/EnJ9yzTXNNtH10tvYSg/Mx+DG1gQwYZiGlHda IRn5YAPD0u6OgL0hwaVPp2GkzheM5m86BJi2mv9lTt7iezlAbia6LfvMxXN0Spr2VU1s 240sD63R/FBAyNFKpQASGhl3D/BwjKt570J0GIHR7cHCu2chs1URrmXqKUhkgpXVmWwj Up9dfcQZelx2sOdHDhr3JxzjZwqjy29tAzDsMLA5fHcMX/4EJJ1c8JdDoCnruSVYihLW f/l9JPjKF8djxKNuSe0ykLjdkpofp4t/u5dQp6lPlbIq84podm8UO6HXo2zGM4WCgIhN 20WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=J0fZ/hfWBt0zaKTmGjpMPgZQc3JrPhDmsIB0zs3wpDo=; b=ftTVwnhiisZGWIZzPqqtiJYdpb5RwZ2R+Y38T9IaRpbdeOQxQES+FSAaJvzc5qOUGk WwmIzlvC7ZhYQz2hT3U23evU4bVm7Dsu4uHvLzMLvarp0/ntAfr35dLrvOHjO8KRudpS Ar+AyxZhVU1NDXZCFSblf0GfbhpD11LfvW7EmAYoo8tOZDzerF3YUrMXmrdWOO+VzZF/ 7sPp4Uzys5BrSI1eqfHLKPt8muUeE5lopStcwAB0PkSIbbI8Qc1KAYMcHShk06ASu2KA N5pXN7Oogy0HX96AHaEphlVIVs0P8EmFtWzx4CtK9pn75cn7MvVhtsjPDwz4LXyc81Y7 lEYA== X-Gm-Message-State: AOAM532Neim2Dz/CyZnA5K9XAT755z+xw50wl6HFjIL51WBZ24pjYfxD sNy45IcQ6w9hZRd2e0c6RepQFg== X-Google-Smtp-Source: ABdhPJxANTI2lBiZ0HsfgvjgPY29ZIPZ2mYXsqUVvo9F4VNeqbPAaQntpPaRsGUq9raxC5WYfCrFuA== X-Received: by 2002:a92:cccb:0:b0:2c2:7641:ed49 with SMTP id u11-20020a92cccb000000b002c27641ed49mr13801966ilq.271.1648735855131; Thu, 31 Mar 2022 07:10:55 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id c2-20020a92dc82000000b002c9b0f25e62sm6948251iln.60.2022.03.31.07.10.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Mar 2022 07:10:54 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id DE4DF80142E; Thu, 31 Mar 2022 09:10:53 -0500 (CDT) Date: Thu, 31 Mar 2022 09:10:53 -0500 From: Justin Pryzby To: Alvaro Herrera Cc: Michael Paquier , =?utf-8?B?5p2O5p2wKOaFjui/vSk=?= , pgsql-hackers@lists.postgresql.org, =?utf-8?B?5pu+5paH5peMKOS5ieS7jik=?= , Zhihong Yu Subject: Re: CLUSTER on partitioned index Message-ID: <20220331141053.GN28503@telsasoft.com> References: <20220223184732.GN9008@telsasoft.com> 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: Archived-At: Precedence: bulk On Wed, Mar 30, 2022 at 10:51:43PM +0200, Alvaro Herrera wrote: > On 2022-Feb-23, Justin Pryzby wrote: > > > I hope that Alvaro will comment on the simplified patches. If multiple people > > think the patch isn't worth it, feel free to close it. But I don't see how > > complexity could be the reason. > > I gave your patch a look and it seems a reasonable thing to do. Maybe > not terribly useful in most cases, but there may be some cases for which > it is. I found some part of it a bit repetitive, so I moved things > around a bit. What do think about this? Thanks for looking at it. The changes to finish_heap_swap() and get_tables_to_cluster() are superfluous, right ? I think this comment is worth preserving (it'd be okay if it lived in the commit message). - * Expand partitioned relations for CLUSTER (the corresponding - * thing for VACUUM FULL happens in and around expand_vacuum_rel() + if (rel != NULL) In this case, maybe it should Assert() that it's relkind=p (mostly for purposes of self-documentation). + partition of the specified partitioned index (which must be specified). This is my own language, but now seems repetitive. I think the parenthetical part should be a separate sentance: "For partitioned indexes, the index may not be omitted.". Otherwise looks ok. diff --git a/doc/src/sgml/ref/cluster.sgml b/doc/src/sgml/ref/cluster.sgml index b3463ae5c46..fbc090cd0b0 100644 --- a/doc/src/sgml/ref/cluster.sgml +++ b/doc/src/sgml/ref/cluster.sgml @@ -199,7 +199,8 @@ CLUSTER [VERBOSE] Clustering a partitioned table clusters each of its partitions using the - partition of the specified partitioned index (which must be specified). + partition of the specified partitioned index. When clustering a + partitioned table, the index may not be omitted. diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c index 8417cbdb67f..412147f05bc 100644 --- a/src/backend/commands/cluster.c +++ b/src/backend/commands/cluster.c @@ -231,6 +231,7 @@ cluster(ParseState *pstate, ClusterStmt *stmt, bool isTopLevel) params.options |= CLUOPT_RECHECK; if (rel != NULL) { + Assert (rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE); check_index_is_clusterable(rel, indexOid, true, AccessShareLock); rtcs = get_tables_to_cluster_partitioned(cluster_context, indexOid); @@ -451,6 +452,7 @@ cluster_rel(Oid tableOid, Oid indexOid, ClusterParams *params) } Assert(OldHeap->rd_rel->relkind == RELKIND_RELATION || + OldHeap->rd_rel->relkind == RELKIND_TOASTVALUE || OldHeap->rd_rel->relkind == RELKIND_MATVIEW); /* diff --git a/src/test/regress/expected/cluster.out b/src/test/regress/expected/cluster.out index 3f2758d13f6..6cf18c8d321 100644 --- a/src/test/regress/expected/cluster.out +++ b/src/test/regress/expected/cluster.out @@ -305,6 +305,8 @@ WHERE pg_class.oid=indexrelid --------- (0 rows) +-- Verify that toast is clusterable +CLUSTER pg_toast.pg_toast_826 USING pg_toast_826_index; -- Verify that clustering all tables does in fact cluster the right ones CREATE USER regress_clstr_user; CREATE TABLE clstr_1 (a INT PRIMARY KEY); diff --git a/src/test/regress/sql/cluster.sql b/src/test/regress/sql/cluster.sql index 74118993a82..ae27c35f65d 100644 --- a/src/test/regress/sql/cluster.sql +++ b/src/test/regress/sql/cluster.sql @@ -104,6 +104,9 @@ WHERE pg_class.oid=indexrelid AND pg_class_2.relname = 'clstr_tst' AND indisclustered; +-- Verify that toast is clusterable +CLUSTER pg_toast.pg_toast_826 USING pg_toast_826_index; + -- Verify that clustering all tables does in fact cluster the right ones CREATE USER regress_clstr_user; CREATE TABLE clstr_1 (a INT PRIMARY KEY);