Re: citext like searches using index

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Thorbjørn Weidemann <thorbjoern(at)weidemann(dot)name>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: citext like searches using index
Date: 2013-04-02 15:03:22
Message-ID: 1720.1364915002@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On 4/2/13 10:26 AM, Tom Lane wrote:
>> The issue with the LIKE special case is that left-anchored patterns
>> are (to some extent) indexable with ordinary btree indexes, and so we
>> want to exploit that rather than tell people they have to have a whole
>> other index.

> In practice, you need an index specifically for pattern matching anyway.

Well, you do if you want to search for general patterns, but there's
been enough interest in the LIKE optimization as-is to make me think
we could not get away with removing it.

>> So it's a pretty special case, but there are just enough instances of it
>> to wish for some not-so-hard-wired way to deal with it.

> Are there any widely known non-built-in cases besides citext?

Well, indxpath.c knows about text LIKE and network subset operators,
and it would be nice if it knew how to do the same type of optimization
for range inclusion, ie btree_indexed_col <@ range_constant. The latter
doesn't seem implementable in the current infrastructure because ranges
aren't all built-in types. I agree that the citext case isn't too
compelling in isolation, but surely the range case is interesting.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2013-04-02 15:32:28 Re: Page replacement algorithm in buffer cache
Previous Message Robert Haas 2013-04-02 14:55:59 Re: Page replacement algorithm in buffer cache