Re: What type of index do I need for this JOIN? - Mailing list pgsql-general

From Kevin Grittner
Subject Re: What type of index do I need for this JOIN?
Date
Msg-id 1376576419.83239.YahooMailNeo@web162906.mail.bf1.yahoo.com
Whole thread Raw
In response to Re: What type of index do I need for this JOIN?  (Robert James <srobertjames@gmail.com>)
List pgsql-general
Robert James <srobertjames@gmail.com> wrote:
> On 8/14/13, Kevin Grittner <kgrittn@ymail.com> wrote:
>> Robert James <srobertjames@gmail.com> wrote:
>>
>>> I'm confused: What's the difference between
>>>   col LIKE  'foo%'
>>> and
>>>   col LIKE f1 || '%'
>>> ?
>>
>> The planner knows that 'foo%' doesn't start with a wildcard.
>>
>>> Either way, it's anchored to the beginning of the string.
>>
>> Not necessarily.
>
> I see, yes, f1 might include a wildcard.

Exactly.

> Is there a way to escape f1 so that wildcards aren't interpreted?
> That's anyway the behavior I need, of course.  And will that help
> the planner?

I don't think there is any way to get that to work in general, and
in particular you are trying to have the right-hand side of the
LIKE treated as having escapes; it would be a lot to ask of the
planner to somehow recognize that part of the result of the
(concatenation) expression should be treated as escaped and part
not.

> What type of index will help the planner here?

Well, with the query as you have it, you might get a trigram index
to be of some help, but I think you might want to give up on LIKE
or regular expressions.  Perhaps you could do a range test
directly, rather than wrangling the wildcards:

  (col >= f1 AND col <= (f1 || 'zzz'))

You would probably want to write a function to calculate that
ending value; I'm just trying to give a rough suggestion here.
The idea is to avoid the danger of wildcards in the f1 values by
constructing the range without scanning for special characters and
basing the test on that.

You could *also* do the LIKE test if desired.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-general by date:

Previous
From: AI Rumman
Date:
Subject: last_vacuum field in not updated
Next
From: Adrian Klaver
Date:
Subject: Re: Getting list of supported types in Postgres