From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: ilike multi-byte pattern cache |
Date: | 2007-09-22 16:04:34 |
Message-ID: | 16505.1190477074@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> The attached patch implements a one-value pattern cache for the
> multi-byte encoding case for ILIKE. This reduces calls to lower() by
> (50% -1) in the common case where the pattern is a constant. My own
> testing and Guillaume Smet's show that this cuts roughly in half the
> performance penalty we inflicted by using lower() in that case.
> Is this sufficiently low risk to sneak into 8.3?
This seems awfully ugly ... and considering that you don't get to
avoid lower() on the data side, it seems pretty dubious that it
buys very much percentagewise. It would also be a net loss for
non-constant patterns, which are by no means unheard of --- or even
two constant patterns used in the same query.
We've lived with this in 8.2 without much complaint. I think we can
let it go until we think of a better solution. To my mind this is
all tied up in the problem of handling locales in a better fashion
--- a lot of the inefficiency of lower() is due to having a poor
impedance match to the libc locale-related functions, and might be
eliminated if we had locale support with better APIs.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-09-22 16:35:48 | Re: ilike multi-byte pattern cache |
Previous Message | Andrew Dunstan | 2007-09-22 14:41:54 | ilike multi-byte pattern cache |