Re: Supporting = operator in gin/gist_trgm_ops - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Supporting = operator in gin/gist_trgm_ops
Date
Msg-id CAPpHfducQ0U8noyb2L3VChsyBMsc5V2Ej2whmEuxmAgHa2jVXg@mail.gmail.com
Whole thread Raw
In response to Re: Supporting = operator in gin/gist_trgm_ops  (Georgios <gkokolatos@protonmail.com>)
Responses Re: Supporting = operator in gin/gist_trgm_ops  (Erik Rijkers <er@xs4all.nl>)
Re: Supporting = operator in gin/gist_trgm_ops  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
Hi!

On Fri, Nov 13, 2020 at 1:47 PM Georgios <gkokolatos@protonmail.com> wrote:
> In short, I think v3 of the patch looks good to change to 'RFC' status.
> Given the possible costing concerns, I will refrain from changing the
> status just yet, to give the opportunity to more reviewers to chime in.
> If in the next few days there are no more reviews, I will update the
> status to 'RFC' to move the patch forward.
>
> Thoughts?

I went through and revised this patch.  I made the documentation
statement less categorical.  pg_trgm gist/gin indexes might have lower
performance of equality operator search than B-tree.  So, we can't
claim the B-tree index is always not needed.  Also, simple comparison
operators are <, <=, >, >=, and they are not supported.

I also have checked that btree_gist is preferred over pg_trgm gist
index for equality search.  Despite our gist cost estimate is quite
dumb, it selects btree_gist index due to its lower size.  So, this
part also looks good to me.

I'm going to push this if no objections.

------
Regards,
Alexander Korotkov

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "pg_ctl: the PID file ... is empty" at end of make check
Next
From: Andy Fan
Date:
Subject: Have we tried to treat CTE as SubQuery in planner?