Yves Dorfsman <y...@zioup.com> writes:
> What about functions that are simpler such as upper()/lower()?

If you think those are simpler, you're much mistaken :-(.  For instance,
"lower(first_name) = 'yves'" would have to be translated to something
like "first_name IN ('yves', 'yveS', 'yvEs', 'yvES', ..., 'YVES')"
-- 16 possibilities altogether, or 2^N for an N-character string.
(And that's just assuming ASCII up/down-casing, never mind the interesting
rules in some non-English languages.)  In a case-sensitive index, those
various strings aren't going to sort consecutively, so we'd end up needing
a separate index probe for each possibility.

extract(year from date) agrees with timestamp comparison up to boundary
cases, that is a few hours either way at a year boundary depending on the
timezone situation.  So you could translate it to a lossy-but-indexable
timestamp comparison condition and not expect to scan too many index items
that don't satisfy the original extract() condition.  But I don't see how
to make something like that work for mapping case-insensitive searches
onto case-sensitive indexes.

                        regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Reply via email to