Re: Supporting = operator in gin/gist_trgm_ops

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Georgios <gkokolatos(at)protonmail(dot)com>
Cc: Julien Rouhaud <julien(dot)rouhaud(at)free(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Supporting = operator in gin/gist_trgm_ops
Date: 2020-11-14 05:30:51
Message-ID: CAPpHfducQ0U8noyb2L3VChsyBMsc5V2Ej2whmEuxmAgHa2jVXg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

On Fri, Nov 13, 2020 at 1:47 PM Georgios <gkokolatos(at)protonmail(dot)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 Content-Type Size
v4-0001-Handle-equality-operator-in-contrib-pg_trgm.patch application/octet-stream 13.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Fan 2020-11-14 06:03:57 Have we tried to treat CTE as SubQuery in planner?
Previous Message Tom Lane 2020-11-14 03:23:51 Re: "pg_ctl: the PID file ... is empty" at end of make check