X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id A0C6611F662D for ; Thu, 30 Mar 2006 08:35:43 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 40039-01 for ; Thu, 30 Mar 2006 08:35:42 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.logix-tt.com (unknown [212.211.145.186]) by postgresql.org (Postfix) with ESMTP id B562211F662B for ; Thu, 30 Mar 2006 08:35:40 -0400 (AST) Received: from kingfisher.intern.logix-tt.com (T8a9b.t.pppool.de [89.55.138.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.logix-tt.com (Postfix) with ESMTP id B497E656CF; Thu, 30 Mar 2006 14:36:21 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kingfisher.intern.logix-tt.com (Postfix) with ESMTP id 31681184D981E; Thu, 30 Mar 2006 14:35:53 +0200 (CEST) Message-ID: <442BD0A9.8050805@logix-tt.com> Date: Thu, 30 Mar 2006 14:35:53 +0200 From: Markus Schaber Organization: Logical Tracking and Tracing International AG, Switzerland User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Eisentraut Cc: pgsql-performance@postgresql.org, Michael Stone Subject: Re: Index scan startup time References: <200603301359.11038.peter_e@gmx.net> <20060330120604.GJ6811@mathom.us> <200603301424.27765.peter_e@gmx.net> In-Reply-To: <200603301424.27765.peter_e@gmx.net> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.114 required=5 tests=[AWL=0.114] X-Spam-Score: 0.114 X-Spam-Level: X-Archive-Number: 200603/613 X-Sequence-Number: 18050 Hi, Peter, Peter Eisentraut wrote: >>>The table has seen VACUUM FULL and REINDEX before this. >>But no analyze? > ANALYZE as well, but the plan choice is not the point anyway. Maybe you could add a combined Index on activity_id and state, or (if you use this kind of query more often) a conditional index on activity_id where state in (10000,10001). Btw, PostgreSQL 8.1 could AND two bitmap index scans on the activity and state indices, and get the result faster (i presume). Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org