Re: [pg_trgm] Making similarity(?, ?) < ? use an index

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Greg Navis <contact(at)gregnavis(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: [pg_trgm] Making similarity(?, ?) < ? use an index
Date: 2016-06-03 20:02:07
Message-ID: 23767.1464984127@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Fri, Jun 3, 2016 at 12:13 PM, Greg Navis <contact(at)gregnavis(dot)com> wrote:
>> I'm curious ... would it be difficult to modify PostgreSQL so that it'd use
>> the index for `similarity(lhs, rhs) >= show_limit()` too?

> Yes, that would be very difficult. The project has kind of painted
> itself into a corner on that.

Well, the thing that is not easy to change is that index scans require
qualifiers expressed as "indexed_column indexable_operator something".
But there's a lot of flexibility about what "something" is. You could
imagine doing, say,

foo ~~ similarity_rhs('bar', 0.01)

where the function just collects its arguments into some composite type
that we provide an indexable operator to compare strings to.

> If it were easy, I doubt we would have added the % operator with the
> ugly set_limit() wart in the first place (although I was not around at
> the time that was done--maybe there were other considerations).

I think that was just bad design. There's a lot of old stuff in contrib
that hasn't been vetted all that closely.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Robert Haas 2016-06-03 20:13:21 Re: [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file
Previous Message David G. Johnston 2016-06-03 19:46:29 Re: [pg_trgm] Making similarity(?, ?) < ? use an index