| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Kenny Bachman <kenny(dot)bachman17(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: postrgesql query planner wrong desicion |
| Date: | 2022-06-19 20:33:33 |
| Message-ID: | CAMkU=1wFNimCgQDYKu5M9ELJjadt1T2BQB_c3PnqqthwGGiFiQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Sat, Jun 18, 2022 at 2:42 AM Kenny Bachman <kenny(dot)bachman17(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kenny Bachman | 2022-06-20 04:54:34 | Re: postrgesql query planner wrong desicion |
| Previous Message | Jeff Janes | 2022-06-18 15:36:45 | Re: postrgesql query planner wrong desicion |