Re: extract(year from date) doesn't use index but maybe could?
От | Gavin Flower |
---|---|
Тема | Re: extract(year from date) doesn't use index but maybe could? |
Дата | |
Msg-id | 55344498.7070101@archidevsys.co.nz обсуждение исходный текст |
Ответ на | Re: extract(year from date) doesn't use index but maybe could? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
On 20/04/15 10:29, Tom Lane wrote: > 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 > > Yeah, an event that happened at 2 am Thursday January 1st 2015 in New Zealand, will be in the year 2014 for people of London in England! Cheers, Gavin
В списке pgsql-performance по дате отправления: