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 1n3iPc-0000wK-Bp for pgsql-bugs@arkaria.postgresql.org; Sat, 01 Jan 2022 17:43:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n3iPZ-00074m-Tn for pgsql-bugs@arkaria.postgresql.org; Sat, 01 Jan 2022 17:43:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n3iPZ-00074d-Lg for pgsql-bugs@lists.postgresql.org; Sat, 01 Jan 2022 17:43:21 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n3iPS-0007a8-H0 for pgsql-bugs@lists.postgresql.org; Sat, 01 Jan 2022 17:43:21 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 201HhAs82878791; Sat, 1 Jan 2022 12:43:11 -0500 From: Tom Lane To: louis.jachiet@telecom-paris.fr cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17350: GIST TRGM Index is broken when combining with combining INCLUDE with a string function (e.g. lower). In-reply-to: <17350-b5bdcf476e5badbb@postgresql.org> References: <17350-b5bdcf476e5badbb@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Thu, 30 Dec 2021 15:47:06 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2878789.1641058990.1@sss.pgh.pa.us> Date: Sat, 01 Jan 2022 12:43:10 -0500 Message-ID: <2878790.1641058990@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > If I issue the > following lines, instead of returning 'foo' and 'bar', postgresql will > return two empty lines: > CREATE EXTENSION IF NOT EXISTS pg_trgm ; > CREATE TABLE t (a VARCHAR(50)); > INSERT INTO t VALUES ('foo') ; > INSERT INTO t VALUES ('BAR') ; > CREATE INDEX test_idx ON t USING gist(lower(a) gist_trgm_ops) INCLUDE > (a) ; > set enable_seqscan=off ; > SELECT lower(a) FROM t ; Fascinating! This is actually a very ancient core-planner bug, though you could not observe it with all index types. The GIST AM correctly reports that it can return the value of a, but not the value of lower(a), in an index-only scan. indxpath.c sees that it can still make an index-only scan, reasoning that lower(a) can be recomputed from the returned value of a. But then set_indexonlyscan_references() screws up: it's told to compute lower(a) from a tlist that includes lower(a) and a, and it naturally figures it can just re-use the first output column. Then at runtime you get a NULL result since that's what the index will output for non-returnable columns. We need some mechanism to mark that not all of the index columns are usable at that step. Doesn't seem terribly hard to fix, though. Thanks for the report! regards, tom lane