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 1maq9h-0000FM-JR for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Oct 2021 02:07:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1maq9e-000299-VC for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Oct 2021 02:07:34 +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 1maq9d-000290-1j for pgsql-hackers@lists.postgresql.org; Thu, 14 Oct 2021 02:07:34 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1maq9Z-0006V2-SG for pgsql-hackers@postgresql.org; Thu, 14 Oct 2021 02:07:31 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 37E043201C28; Wed, 13 Oct 2021 22:07:27 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 13 Oct 2021 22:07:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=kgMo+OzhzQ70d1VHnPlIshpE6dh oG3s3xpIwCAZ1Cpc=; b=BFl8rPC67yQDGeqDCDfakLVZSxXCev9BdpP9MsKvnMT Z1rM6YXPO74dt/bvUluZuS5JVd6EwRPMLDx4FCp3qBVUSQKBoUjtFCF3A3QP93lK 7Yth/XnOarO1pETbkKsHRXzwZTuKYaJHpL1amb7oTH89Md/jmkKZr1uH9Fh/60HJ jQS868N9CYQLroP08PEoa3tGf1EMsbqXGZegykNKWKR9AMJTqmuPP8pTQXzw6diE 8bx5m6ArWxmfN+umLWNYpGlT4IzWOiVyuk0sz0qm3puh4EDqQGNnOXhHZkKwTS9Z nP0yHVNQ3Hntg1Pd1GepdIRaH9NVZEy/wrBjxxC/g2w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=kgMo+O zhzQ70d1VHnPlIshpE6dhoG3s3xpIwCAZ1Cpc=; b=g+aPjJ0MWA2Q+5TLb/LdiF 6z6WQtf7f6zLHllwB+83wY84YwNMNOU6Ad0fFlg4BTinQQRIPldGGkErA4mbcUtn INB+/Gw4BjEdmSCxyzqJwodT1ayHo7fNFzDkX41J1A5S+lyubkIuH19tkpO2gFUu I2/8vm5hAxPxBe+Gt37Nh8OW8eN+ouv8UJKI7JrPeZTTHPhgEgpD02wsrlF+72Xa p7vrbivHLx1sk/jmxIKYi4zNy/gTB8VGbiY0VWME8udwGC3QSet59sswpjj/B8XG +NmfHAuj6JFs3VMHAd19Tk0dNIi4+pKS4KlL3wUl4YA9c7QpW/D3Fk9dDRJxdKwg == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdduuddghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdlfeehmdenucfjughrpeffhffvuffkfhggtggujgesghdtreertddt vdenucfhrhhomhepofhitghhrggvlhcurfgrqhhuihgvrhcuoehmihgthhgrvghlsehprg hquhhivghrrdighiiiqeenucggtffrrghtthgvrhhnpeffudeffeelgffhkedukeekvedv udfgieetkeekudelfeevhffhffdtudffieeutdenucffohhmrghinhepphhoshhtghhrvg hsqhhlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepmhhitghhrggvlhesphgrqhhuihgvrhdrgiihii X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 13 Oct 2021 22:07:23 -0400 (EDT) Date: Thu, 14 Oct 2021 11:07:21 +0900 From: Michael Paquier To: "Bossart, Nathan" Cc: Dilip Kumar , Vik Fearing , "postgresql@zr40.nl" , Alexander Korotkov , "pgsql-hackers@postgresql.org" , Robert Haas Subject: Re: BUG #17220: ALTER INDEX ALTER COLUMN SET (..) with an optionless opclass makes index and table unusable Message-ID: References: <17220-15d684c6c2171a83@postgresql.org> <9b91d241-4d05-e5a4-67da-5b8acdb9a2f1@postgresfriends.org> <678CF71A-934B-4FD0-BF63-E41D795E41C9@amazon.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6jTfDcuGz5JwzWtO" Content-Disposition: inline In-Reply-To: <678CF71A-934B-4FD0-BF63-E41D795E41C9@amazon.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --6jTfDcuGz5JwzWtO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Oct 13, 2021 at 05:20:56PM +0000, Bossart, Nathan wrote: > AFAICT the fact that these commands can succeed at all seems to be > unintentional, and I wonder if modifying these options requires extra > steps such as rebuilding the index. I was looking at all this business with more attention, and this code block is standing out in analyze.c: /* * Now we can compute the statistics for the expression columns. */ if (numindexrows > 0) { MemoryContextSwitchTo(col_context); for (i = 0; i < attr_cnt; i++) { VacAttrStats *stats = thisdata->vacattrstats[i]; AttributeOpts *aopt = get_attribute_options(stats->attr->attrelid, stats->attr->attnum); stats->exprvals = exprvals + i; stats->exprnulls = exprnulls + i; stats->rowstride = attr_cnt; stats->compute_stats(stats, ind_fetch_func, numindexrows, totalindexrows); /* * If the n_distinct option is specified, it overrides the * above computation. For indices, we always use just * n_distinct, not n_distinct_inherited. */ if (aopt != NULL && aopt->n_distinct != 0.0) stats->stadistinct = aopt->n_distinct; MemoryContextResetAndDeleteChildren(col_context); } } When computing statistics on an index expression, this code means that we would grab the value of n_distinct from the *index* if set and force the stats to use it, and not use what the parent table has. For example, say: create table aa (a int); insert into aa values (generate_series(1,1000)); create index aai on aa((a+a)) where a > 500; alter index aai alter column expr set (n_distinct = 2); analyze aa; -- n_distinct forced to 2.0 for the index stats This code comes from 76a47c0 back in 2010. In PG <= 12, this would work, but that does not as of 13~. Enforcing n_distinct for index attributes was discussed back when this code was introduced: https://www.postgresql.org/message-id/603c8f071001101127w3253899vb3f3e15073638774@mail.gmail.com This means that we've lost the ability to enforce n_distinct for expression indexes for two years. But, do we really care about this case? My answer to that would be "no" as long as we don't have a documented grammar rather, and we don't dump them either. But I think that we'd better do something with the code in analyze.c rather than letting it just dead, and my take is that we should remove the call to get_attribute_options() for this code path. Any opinions? @Robert: you were involved in 76a47c0, so I am adding you in CC. -- Michael --6jTfDcuGz5JwzWtO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmFnkNgACgkQnvQgOdby QH2Olg//QwBOVZMTWDgRuL9YijUu2KmaOwk/Y4HK8gLm37lf3ArWe+dnBCNtOgIj ynXpD6RjD1a25WfICXtFQCAbYbBOOAJqF/nIlxJfVCle+PtjBWcX0T1118xivwHJ OinN0NXi5creFrz9KEl57VfWtR7Lh2BYC4pdbSLJH54Z0ETi2MMp48wRe5jEWoVD 4HX/OeJBTqvbI09mG0pM1vN3is667Km1pj1Rz8I7N8Crwsw9p8llTQtpvN/AvJC8 rZCi5Xdu59KBpIMyGcNceZ2jpR/Mr8YSXIQH6NRixs8KyZxwVyGX8KvMoEu/qiZH OxS4uSU0jMy0R5vb/ipz9IlD9MXK99v6/cAdk0j/CMz6ysyzd+sefJ5gLkWs5srZ l2pcw++aN1blzDXRAOenMzzrt4orhDXAdPthQg6u+NKch+riFC+j8mc0syOwzlmb +pZ+OKAC7bQCp2tlLEfvDSQorArZQRPrJaleqV8HUqU7/Rijimj6nCm1sXaTw8GJ cRf1lC9UTk2SEe3ergQSkreiVr078ASomdzcxFOdG24ASbZHrAZd+juyBhxQK1zS JOh/Zxc0OBCX5s0XN1TsXwiB/6Z+12sDeWGgaU4dOWNYKAqLkpjCprWnl+0T1DV5 6teCkRddl59Kr7X/nuyA/zY09JT5EdMlMh2pM7af8lLrYuzJjEA= =jM1g -----END PGP SIGNATURE----- --6jTfDcuGz5JwzWtO--