Re: postrgesql query planner wrong desicion - Mailing list pgsql-admin

From Jeff Janes
Subject Re: postrgesql query planner wrong desicion
Date
Msg-id CAMkU=1wFNimCgQDYKu5M9ELJjadt1T2BQB_c3PnqqthwGGiFiQ@mail.gmail.com
Whole thread Raw
In response to Re: postrgesql query planner wrong desicion  (Kenny Bachman <kenny.bachman17@gmail.com>)
Responses Re: postrgesql query planner wrong desicion  (Kenny Bachman <kenny.bachman17@gmail.com>)
List pgsql-admin
On Sat, Jun 18, 2022 at 2:42 AM Kenny Bachman <kenny.bachman17@gmail.com> wrote:
Hi Tom,

The gist index is used by other queries with LIKE or ILIKE operators. Should I drop the gist index for text or varchar columns?

This story doesn't make sense to me.  The gist operator for text provided by btree_gist does not support LIKE (other than in the same way btree indexing does), so there is no point in making one of those indexes for this purpose.  And the gist operator for text provided by pg_trgm does not support equality (until PostgreSQL v14) so that type of index would not "capture" the equality comparison in v12.11.  If not one of those two, then where are you getting your gist operator class from?

That is not to say the costing of GiST indexes shouldn't be improved, but I don't see how it could sensibly be causing this problem under v12.

Cheers,

Jeff

pgsql-admin by date:

Previous
From: Jeff Janes
Date:
Subject: Re: postrgesql query planner wrong desicion
Next
From: Kenny Bachman
Date:
Subject: Re: postrgesql query planner wrong desicion