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 1ggafC-00014K-Sr for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Jan 2019 19:34:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ggafB-000716-10 for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Jan 2019 19:34:17 +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 1ggafA-0006z0-LM for pgsql-hackers@lists.postgresql.org; Mon, 07 Jan 2019 19:34:16 +0000 Received: from mail-it1-x144.google.com ([2607:f8b0:4864:20::144]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ggaf6-0006hm-Ri for pgsql-hackers@postgresql.org; Mon, 07 Jan 2019 19:34:15 +0000 Received: by mail-it1-x144.google.com with SMTP id i145so2861356ita.4 for ; Mon, 07 Jan 2019 11:34:12 -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=ir57kjp4wLAE2d1xrDo0k2sw8AH0tx3hXltNS4CCjxY=; b=gWSJ/LaRCQZl0f5/xXLHIGnyifj5RK1IQO3vdxulebUXuDyP1raIPePF5CLEwByVhg 7H044cZuq5q3s/SFtCKLVCJEoDgOmnE7n+xAVXexBTLicYYpkeKXohdePsud+OnTRIw0 HG8Bv1s7NIJVWIULIEMN6IhB7WkA7n3qV1mMx1RQtSpDckhE/nSIQhEXLR4KyRl0wEZt h+fR5xaL6+/y6R1v4hX2qc3BQSkg7g5WA39/UauPgcG9pq2P2dnCu7eZyKRlYFuakKDu xJzmg+DXOiampmYrUfP8OYXVhpveNQpRBvap/uN/TFF7lCKbzq107rEz9eJo5Q5tiVNT o07A== 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=ir57kjp4wLAE2d1xrDo0k2sw8AH0tx3hXltNS4CCjxY=; b=HTSSk0eVDZUs/61JxhbiANV4Z/KUDm1V96ecTtmrV5l59cau3BhL8CKvSWQ3MijFtz OPMBBJoU8IGmOuMojRlDl+WVrdmOta/bL7AAdSQy6mkkBygmVTyHjOf3XGFwsB+cs70E shkOKO+RFTJa6bHKmYThZ8va6as+NAc7c17cJJZ0wjAUJa1WmNzeyBnfWNssoCaA2Jqp X9h8Xv409gaPj7NmQ1XuiZG6zOlnJ+5V+137PWs4N3jiJP1RVDof7iRL0CigL1yfYpkW SMCdveY833h9PsIsKjyPjFTogunEINjf+usOBmcLtbABXyVGrTWV6AWoIUACgz9QFb0q nkiQ== X-Gm-Message-State: AJcUukf8WfC+UPM7MYW2TEpQJvcgZ9d8j4uhtTZwtyDGXPlg99STITfw atVgrg0QwI2iC99ibRIA9kttEA== X-Google-Smtp-Source: ALg8bN4Au+55B0ZaOtvb4zJUwAzK6KzM/mj9EcqQnlaQf6Dqgng/GLxFDtyRl6TSY3MqSBsnGriJGg== X-Received: by 2002:a24:4e0d:: with SMTP id r13mr7688608ita.140.1546889650538; Mon, 07 Jan 2019 11:34:10 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id m81sm4531276itb.43.2019.01.07.11.34.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Jan 2019 11:34:09 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 7D0F3801065; Mon, 7 Jan 2019 13:34:08 -0600 (CST) Date: Mon, 7 Jan 2019 13:34:08 -0600 From: Justin Pryzby To: Alvaro Herrera Cc: pgsql-hackers@postgresql.org Subject: Re: ALTER INDEX fails on partitioned index Message-ID: <20190107193408.GD25379@telsasoft.com> References: <20190105185937.GO25379@telsasoft.com> <201901071923.7r2xflxvncly@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201901071923.7r2xflxvncly@alvherre.pgsql> User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Jan 07, 2019 at 04:23:30PM -0300, Alvaro Herrera wrote: > On 2019-Jan-05, Justin Pryzby wrote: > > > 12dev and 11.1: > > > > postgres=# CREATE TABLE t(i int)PARTITION BY RANGE(i); > > postgres=# CREATE INDEX ON t(i) WITH(fillfactor=11); > > postgres=# ALTER INDEX t_i_idx SET (fillfactor=12); > > ERROR: 42809: "t_i_idx" is not a table, view, materialized view, or index > > LOCATION: ATWrongRelkindError, tablecmds.c:5031 > > > > I can't see that's deliberate, > > Well, I deliberately ignored that aspect of the report at the time as it > seemed to me (per discussion in thread [1]) that this behavior was > intentional. However, if I think in terms of things like > pages_per_range in BRIN indexes, this decision seems to be a mistake, > because surely we should propagate that value to children. > > [1] https://www.postgresql.org/message-id/flat/CAH2-WzkOKptQiE51Bh4_xeEHhaBwHkZkGtKizrFMgEkfUuRRQg%40mail.gmail.com I don't see any discussion regarding ALTER (?) Actually, I ran into this while trying to set pages_per_range. But shouldn't it also work for fillfactor ? Thanks, Justin