Horton

Re: BUG #17350: GIST TRGM Index is broken when combining with combining INCLUDE with a string function (e.g. lower).

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: louis.jachiet@telecom-paris.fr
Cc: pgsql-bugs@lists.postgresql.org
Date: 2022-01-01T17:43:10Z
Lists: pgsql-bugs 
PG Bug reporting form <noreply@postgresql.org> 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

Commits

  1. Fix index-only scan plans, take 2.

  2. Fix index-only scan plans when not all index columns can be returned.