Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 386C09FA13C for ; Mon, 16 Apr 2007 20:01:17 -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 59642-02 for ; Mon, 16 Apr 2007 20:01:08 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from lists.commandprompt.com (host-254.commandprompt.net [207.173.203.254]) by postgresql.org (Postfix) with ESMTP id 0AAAB9FA521 for ; Mon, 16 Apr 2007 20:01:07 -0300 (ADT) Received: from perhan.alvh.no-ip.org (201-221-221-161.bk12-dsl.surnet.cl [201.221.221.161]) (authenticated bits=0) by lists.commandprompt.com (8.13.7/8.13.6) with ESMTP id l3GN197Q030870; Mon, 16 Apr 2007 16:01:10 -0700 Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id CFECE329F8; Mon, 16 Apr 2007 19:01:04 -0400 (CLT) Date: Mon, 16 Apr 2007 19:01:04 -0400 From: Alvaro Herrera To: Steve Cc: Tom Lane , pgsql-patches@postgreSQL.org Subject: Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM] Strangely Variable Query Performance) Message-ID: <20070416230104.GY5658@alvh.no-ip.org> Mail-Followup-To: Steve , Tom Lane , pgsql-patches@postgreSQL.org References: <12360.1176436194@sss.pgh.pa.us> <26399.1176504501@sss.pgh.pa.us> <20070413232409.GI27255@alvh.no-ip.org> <7772.1176574886@sss.pgh.pa.us> <23414.1176588173@sss.pgh.pa.us> <26103.1176613862@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: ClamAV version 0.88.5, clamav-milter version 0.88.5 on projects.commandprompt.com X-Virus-Status: Clean X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (lists.commandprompt.com [192.168.2.159]); Mon, 16 Apr 2007 16:01:10 -0700 (PDT) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/395 X-Sequence-Number: 1962 Steve wrote: > >Can you find any cases where it makes a worse choice than before? > >Another thing to pay attention to is whether the planning time gets > >noticeably worse. If we can't find any cases where it loses badly > >on those measures, I'll feel comfortable in applying it... > > Okay, here's the vedict; all the "extremely slow" queries (i.e. > queries that took more than 30 seconds and upwards of several minutes to > complete) are now running in the realm of reason. In fact, most queries > that took between 1 and 4 minutes are now down to taking about 9 seconds > which is obviously a tremendous improvement. > > A few of the queries that were taking 9 seconds or less are > "slightly slower" -- meaning a second or two slower. However most of them > are running at the same speed they were before, or better. > > So I'd say as far as I can tell with my application and my > dataset, this change is solid and an obvious improvement. Maybe it would be interesting to see in detail those cases that got a bit slower, to further tweak the heuristic if necessary. Is the extra time, time spent in planning or in execution? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support