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

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: [pg_trgm] Making similarity(?, ?) < ? use an index
Дата
Msg-id CAMkU=1w1nzchfDHpS9JNMjqq9TPzfSUuY+nnRHmqGVA93LzeJQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [pg_trgm] Making similarity(?, ?) < ? use an index  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [pg_trgm] Making similarity(?, ?) < ? use an index  (Greg Navis <contact@gregnavis.com>)
Список pgsql-general
On Fri, Jun 3, 2016 at 1:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>> On Fri, Jun 3, 2016 at 12:13 PM, Greg Navis <contact@gregnavis.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.

Oh, interesting.  I was thinking we would need to have the operator
receive the parsed but unevaluated expression "tree" (which I didn't
think was possible to do) and then somehow rewrite that structure.
Collecting it into a composite and passing the composite to the
operator does open up a lot of possibilities I hadn't considered.

Cheers,

Jeff


В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [pg_trgm] Making similarity(?, ?) < ? use an index
Следующее
От: rverghese
Дата:
Сообщение: Partitioned postgres tables don't need update trigger??