Received: from localhost (maia-1.hub.org [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 405479FB8E6
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 25 May 2007 12:35:39 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024)
	with ESMTP id 35193-03 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 25 May 2007 12:35:35 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from mail.metronet.co.uk (mail.metronet.co.uk [213.162.97.75])
	by postgresql.org (Postfix) with ESMTP id E8CAF9FB6AF
	for <pgsql-performance@postgresql.org>;
	Fri, 25 May 2007 12:35:34 -0300 (ADT)
Received: from server3.office.archonet.com
	(84-51-143-99.archon037.adsl.metronet.co.uk [84.51.143.99])
	by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id 4DA9E74ADF;
	Fri, 25 May 2007 16:35:23 +0100 (BST)
Received: from [192.168.1.36] (dell36.office.archonet.com [192.168.1.36])
	by server3.office.archonet.com (Postfix) with ESMTP id A7BFF27410E;
	Fri, 25 May 2007 16:35:26 +0100 (BST)
Message-ID: <4657023A.20209@archonet.com>
Date: Fri, 25 May 2007 16:35:22 +0100
From: Richard Huxton <dev@archonet.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: mark@mark.mielke.cc
Cc: Mark Lewis <mark.lewis@mir3.com>,
	James Mansion <james@mansionfamily.plus.com>,
	Magnus Hagander <magnus@hagander.net>,
	Alexander Staubo <alex@purefiction.net>, Andy <frum@ar-sd.net>,
	pgsql-performance@postgresql.org
Subject: Re: LIKE search and performance
References: <009501c79d4c$445428f0$0b00a8c0@mpsro.dom>
	<88daf38c0705230905u1a981102k691b47bd36011a80@mail.gmail.com>
	<4655DE75.4080506@mansionfamily.plus.com>
	<4655E64B.5050503@hagander.net>
	<4655FB8A.1040707@mansionfamily.plus.com>
	<1180040560.31471.262.camel@archimedes>
	<20070524215450.GA3858@mark.mielke.cc>
	<46569AA5.10205@archonet.com>
	<20070525141630.GA12162@mark.mielke.cc>
In-Reply-To: <20070525141630.GA12162@mark.mielke.cc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200705/517
X-Sequence-Number: 24907

mark@mark.mielke.cc wrote:
> On Fri, May 25, 2007 at 09:13:25AM +0100, Richard Huxton wrote:
>> mark@mark.mielke.cc wrote:
>>>> And since it's basically impossible to know the selectivity of this kind
>>>> of where condition, I doubt the planner would ever realistically want to
>>>> choose that plan anyway because of its poor worst-case behavior.
>>> What is a real life example where an intelligent and researched
>>> database application would issue a like or ilike query as their
>>> primary condition in a situation where they expected very high
>>> selectivity?
>>> Avoiding a poor worst-case behaviour for a worst-case behaviour that
>>> won't happen doesn't seem practical.
>> But if you are also filtering on e.g. date, and that has an index with 
>> good selectivity, you're never going to use the text index anyway are 
>> you? If you've only got a dozen rows to check against, might as well 
>> just read them in.
>> The only time it's worth considering the behaviour at all is *if* the 
>> worst-case is possible.
> 
> I notice you did not provide a real life example as requested. :-)

OK - any application that allows user-built queries: <choose column: 
foo> <choose filter: contains> <choose target: "bar">

Want another? Any application that has a "search by name" box - users 
can (and do) put one letter in and hit enter.

Unfortunately you don't always have control over the selectivity of 
queries issued.

> This seems like an ivory tower restriction. Not allowing best performance
> in a common situation vs not allowing worst performance in a not-so-common
> situation.

What best performance plan are you thinking of? I'm assuming we're 
talking about trailing-wildcard matches here, rather than "contains" 
style matches.

-- 
   Richard Huxton
   Archonet Ltd