Yves Dorfsman <yves@xxxxxxxxx> 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@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
