Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 682D79FBA47 for ; Thu, 24 May 2007 18:55:08 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 32450-03 for ; Thu, 24 May 2007 18:55:04 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id F0FD89FBA31 for ; Thu, 24 May 2007 18:55:04 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 Received: from mail.envysolutions.com (unknown [206.248.142.186]) by svr4.postgresql.org (Postfix) with ESMTP id 264005AF028 for ; Thu, 24 May 2007 21:55:04 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.envysolutions.com (Postfix) with ESMTP id 5011E5404E; Thu, 24 May 2007 17:54:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.envysolutions.com Received: from mail.envysolutions.com ([127.0.0.1]) by localhost (mark.mielke.cc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKCDJSeRgool; Thu, 24 May 2007 17:54:51 -0400 (EDT) Received: by mail.envysolutions.com (Postfix, from userid 500) id 2AD565404F; Thu, 24 May 2007 17:54:51 -0400 (EDT) Date: Thu, 24 May 2007 17:54:51 -0400 From: mark@mark.mielke.cc To: Mark Lewis Cc: James Mansion , Magnus Hagander , Alexander Staubo , Andy , pgsql-performance@postgresql.org Subject: Re: LIKE search and performance Message-ID: <20070524215450.GA3858@mark.mielke.cc> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1180040560.31471.262.camel@archimedes> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.86 tagged_above=0 required=5 tests=AWL=-0.237, BAYES_50=0.001, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961 X-Spam-Level: X-Archive-Number: 200705/482 X-Sequence-Number: 24872 On Thu, May 24, 2007 at 02:02:40PM -0700, Mark Lewis wrote: > PG could scan the index looking for matches first and only load the > actual rows if it found a match, but that could only be a possible win > if there were very few matches, because the difference in cost between a > full index scan and a sequential scan would need to be greater than the > cost of randomly fetching all of the matching data rows from the table > to look up the visibility information. > So yes it would be possible, but the odds of it being faster than a > sequential scan are small enough to make it not very useful. > 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. What real life examples, that could not be implemented a better way, would behave poorly if like/ilike looked at the index first to filter? I don't understand... :-) Cheers, mark -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/