Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 305919FB374; Sat, 14 Apr 2007 05:28:19 -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 77651-02; Sat, 14 Apr 2007 05:28:12 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail01.enterprisedb.com (mail01.enterprisedb.com [63.246.7.168]) by postgresql.org (Postfix) with ESMTP id 5767A9FB289; Sat, 14 Apr 2007 05:28:15 -0300 (ADT) thread-index: Acd+buFL1w3VQBqzTSe0GmhI7/7xtg== Received: from [192.168.0.22] ([85.211.22.118]) by mail01.enterprisedb.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Apr 2007 04:28:29 -0400 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Subject: Re: choose_bitmap_and again (was Re: [PERFORM] StrangelyVariable Query Performance) From: "Simon Riggs" To: "Tom Lane" Cc: , "PostgreSQL Performance" , "Steve" In-Reply-To: <26399.1176504501@sss.pgh.pa.us> References: <57271CC2-BCB1-4ACA-A177-4FF64F1BC33F@brandeis.edu> <16E9A17C-ADFA-43B2-B7EA-5C7A4D7E96D1@event-s.net> <0914C05F-BA1B-4A6C-A1B1-52256BC851A4@event-s.net> <1176396964.13754.16.camel@state.g2switchworks.com> <1176414724.13754.23.camel@state.g2switchworks.com> <1176416077.13754.26.camel@state.g2switchworks.com> <9833.1176418809@sss.pgh.pa.us> <10117.1176420763@sss.pgh.pa.us> <10355.1176422445@sss.pgh.pa.us> <10503.1176423606@sss.pgh.pa.us> <12360.1176436194@sss.pgh.pa.us> <26399.1176504501@sss.pgh.pa.us> Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 14 Apr 2007 09:24:07 +0100 Message-ID: <1176539048.3635.316.camel@silverbirch.site> MIME-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2007 08:28:29.0406 (UTC) FILETIME=[E14227E0:01C77E6E] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/629 X-Sequence-Number: 101962 On Fri, 2007-04-13 at 18:48 -0400, Tom Lane wrote: > Has anyone got any thoughts about the best way to do this? I don't think we know enough to pick one variant that works in all cases. This requires more detailed analysis of various cases. Lets put in a parameter to allow the options to be varied. The purpose would be to look for some more information that allows us to see what the pre-conditions would be for each heuristic. Initially, we say this is a beta-only feature and may be withdrawn in the production version. Why did it not pick my index? is a tiring game, but one that must be played. I hope that the ORDER LIMIT optimization should reduce the number of indexes chosen to maintain sort order in the output. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com