Re: BUG #14032: trigram index is not used for '=' operator

From: Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: ruslan(dot)zakirov(at)gmail(dot)com, Pg Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14032: trigram index is not used for '=' operator
Date: 2016-03-21 08:28:52
Message-ID: 56EFB0C4.2000308@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 20.03.2016 04:06, Jeff Janes wrote:
>
> I think it is actually quite trivial to support '='. In fact I think
> that all you have to do is tap into the same code that LIKE already
> uses, and let the recheck remove things which match on the LIKE
> interpretation of the query string but not the equality
> interpretation.
>
> Attached is a crude patch I put together which seems to do the job,
> but I haven't thoroughly tested it.
>
> The main problem is likely to be that there is already a really good
> index type for speeding up equality queries (btree), and adding
> another (generally much worse) alternative is likely to confuse the
> planner more than anything. Is it really worth taking the performance
> hit on executing the equality query in order to avoid just keeping a
> second btree index?

Maybe not :)

>
> If I could somehow turn this into an extension module that installed
> with pg_trgm as a dependency, rather than reaching into pg_trgm's
> internals, then it might be worthwhile putting something like this on
> PGXN. But I don't know how to do that. And it doesn't seem
> worthwhile to change pg_trgm itself in this way.
>
> But in any case, it isn't a bug that pg_trgm doesn't do everything it
> theoretically could do.

Yes. And so this changes can be applied only for PostgreSQL 9.7.

>
> Cheers,
>
> Jeff
>

--
Artur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Inoue, Hiroshi 2016-03-21 10:41:06 Re: Re: [BUGS] BUG #14023: pq odbc driver crashed while get data from boolean column
Previous Message Thom Brown 2016-03-20 19:55:26 Breakage with VACUUM ANALYSE + partitions