Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 4D0B19FC001 for ; Fri, 25 May 2007 14:32:53 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 03537-01-2 for ; Fri, 25 May 2007 14:32:43 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail.metronet.co.uk (mail.metronet.co.uk [213.162.97.75]) by postgresql.org (Postfix) with ESMTP id CDFE09FBF75 for ; Fri, 25 May 2007 14:32:44 -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 BD9007580E; Fri, 25 May 2007 18:32:39 +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 C8BE42740EB; Fri, 25 May 2007 18:32:43 +0100 (BST) Message-ID: <46571DB7.2040607@archonet.com> Date: Fri, 25 May 2007 18:32:39 +0100 From: Richard Huxton User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: PFC Cc: mark@mark.mielke.cc, Mark Lewis , James Mansion , Magnus Hagander , Alexander Staubo , Andy , 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> <4657023A.20209@archonet.com> <46571825.30707@archonet.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200705/528 X-Sequence-Number: 24918 PFC wrote: >> None of which address the question of what plan PG should produce for: >> SELECT * FROM bigtable WHERE foo LIKE 's%' > > Ah, this one already uses the btree since the '%' is at the end. > My point is that a search like this will yield too many results to > be useful to the user anyway, so optimizing its performance is a kind of > red herring. At the *application level* yes. At the *query planner* level no. At the query planner level I just want it to come up with the best plan it can. The original argument was that PG's estimate of the number of matching rows was too optimistic (or pessimistic) in the case where we are doing a contains substring-search. -- Richard Huxton Archonet Ltd