X-Original-To: pgsql-bugs-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id D015D9FA322 for ; Tue, 4 Jul 2006 05:59:36 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 65860-08 for ; Tue, 4 Jul 2006 05:59:27 -0300 (ADT) X-Greylist: delayed 00:21:48.380731 by SQLgrey- Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id 287099FB1BA for ; Tue, 4 Jul 2006 05:59:27 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 Received: from pancernik.batory.org.pl (pancernik.batory.org.pl [62.89.72.210]) by svr4.postgresql.org (Postfix) with ESMTP id 62A165AF04E for ; Tue, 4 Jul 2006 08:37:37 +0000 (GMT) Received: from pancernik.batory.org.pl (localhost.localdomain [127.0.0.1]) by pancernik.batory.org.pl (8.13.6/8.13.6) with ESMTP id k648bYba020295; Tue, 4 Jul 2006 10:37:34 +0200 Received: (from tometzky@localhost) by pancernik.batory.org.pl (8.13.6/8.13.6/Submit) id k648bXbp020294; Tue, 4 Jul 2006 10:37:33 +0200 Date: Tue, 4 Jul 2006 10:37:33 +0200 From: Tomasz Ostrowski To: Tom Lane Cc: pgsql-bugs@postgresql.org Subject: Re: query very slow when enable_seqscan=on Message-ID: <20060704083733.GA20102@batory.org.pl> References: <20060703203105.GA2801@batory.org.pl> <7353.1151967946@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7353.1151967946@sss.pgh.pa.us> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200607/15 X-Sequence-Number: 15360 On Mon, 03 Jul 2006, Tom Lane wrote: > > -> Seq Scan on organization (cost=0.00..480.95 rows=1 width=4) (actual time=0.071..69.702 rows=1892 loops=1) > > Filter: ((organization_location)::text ~* 'warszawa'::text) > > How many rows are there in the organization table? About 9000. And about 6500 persons. "Warszawa" is a biggest city in Poland and a capital - many organizations are located there. > This is probably the fault of the pattern-selectivity heuristic: > it's far too optimistic about long match strings eliminating a lot > of rows. I think there's been some discussion of modifying that > logic but no one's really stepped up with a better idea. I think because there is no good solution to this - no statistical information is going to predict how much data will match a regular expression. Maybe in this situation an algorithm should be pessimistic - that it will return all rows, or all non-null rows or all rows no shorter than matching string (if it's a string and not for example regex like [abcdefghijklmnopqrstuvwxyz] which is long but will match basicaly everything). In my opinion it is better to overestimate most of the time than to risk underestimation by a factor of 1000 and more. For now I'm turning off seqscans. This is a second time I got terrible permormance with seqscans turned on because of bad estimation. And my database will probably fit in cache. Regards Tometzky -- ...although Eating Honey was a very good thing to do, there was a moment just before you began to eat it which was better than when you were... Winnie the Pooh