Re: extract(year from date) doesn't use index but maybe could?
| От | Tom Lane |
|---|---|
| Тема | Re: extract(year from date) doesn't use index but maybe could? |
| Дата | |
| Msg-id | 6398.1429482594@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: extract(year from date) doesn't use index but maybe could? (Yves Dorfsman <yves@zioup.com>) |
| Ответы |
Re: extract(year from date) doesn't use index but maybe
could?
|
| Список | pgsql-performance |
Yves Dorfsman <yves@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
В списке pgsql-performance по дате отправления: