On 3/19/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Not if you have an index on lower(col) which one supposes you'd have
anyway for such an application. Or are you running an ancient PG
release?
Yes, you're right. Looking at my history I can't find what my error
was - I analyzed the table several
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> The usual trick recommended in the doc is to use lower() and LIKE but
> it leads to bad row estimates (it's constant whatever the search
> pattern is)
Not if you have an index on lower(col) which one supposes you'd have
anyway for such an application.
On 3/18/07, Martijn van Oosterhout wrote:
Er, it's link between LIKE and the ~=~ that's hard coded
Yes.
So I think it's easier that you think: just build the operator class
and make sure you use the right operator so the planner uses it. ILIKE
already maps to an operator...
Yeah I know. Th
On Sun, Mar 18, 2007 at 07:30:35PM +0100, Guillaume Smet wrote:
> I have planned to write the operator class as a "contrib" module but I
> couldn't find the link between LIKE operator and text_pattern_ops
> opclass which uses ~=~ and all its variants. Andrew from Supernews
> told me it was hardcode
Hi all,
I'm currently facing a common problem with queries using ILIKE: it
can't use an index except if the pattern begins with non alpha
characters.
The usual trick recommended in the doc is to use lower() and LIKE but
it leads to bad row estimates (it's constant whatever the search
pattern is)
