Re: Case Insensitive

From: Steve Atkins <steve(at)blighty(dot)com>
To: PG mailing List <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Case Insensitive
Date: 2019-03-28 09:30:21
Message-ID: 3C4DCC9E-C7D0-4DD6-90E7-CF3C30FCE146@blighty.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-general

> On Mar 28, 2019, at 9:08 AM, Ron <ronljohnsonjr(at)gmail(dot)com> wrote:
>
> On 3/28/19 3:33 AM, Steve Atkins wrote:
>>
>>> On Mar 28, 2019, at 8:29 AM, Ron <ronljohnsonjr(at)gmail(dot)com> wrote:
>>>
>>> On 3/28/19 3:23 AM, Sameer Kumar wrote:
>>> [snip]
>>>> You can write a query with upper function:
>>>>
>>>> select * from emp where upper(ename)=upper('aaa');
>>> That's a guaranteed table scan.
>> Unless you have an index on upper(ename).
>
> Are you sure? I thought the lpart had to be immutable for the query optimizer to decide to use an index (and upper(ename) is mutable).

Yeah. Case insensitive searches like this are pretty much the first example given for why you might want to use an expression index.

The expression in an expression index has to be immutable, but upper() is - it will always give the same output for a given input. (For values of "always" that probably depend on not performing major surgery on collations, but that falls into the "lie to the planner, get rotten results" category).

Check "\df+ upper"

Cheers,
Steve

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Holger Jakobs 2019-03-28 11:01:07 Re: Case Insensitive
Previous Message Peter Eisentraut 2019-03-28 09:24:58 Re: Case Insensitive

Browse pgsql-general by date

  From Date Subject
Next Message Prakash Ramakrishnan 2019-03-28 10:20:55 Re: plctl extension issue postgresql 11.2
Previous Message Peter Eisentraut 2019-03-28 09:24:58 Re: Case Insensitive