Received: from localhost (maia-1.hub.org [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id C3B1F9FBA01
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 12 Apr 2007 18:24:56 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024)
	with ESMTP id 16204-01 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 12 Apr 2007 18:24:53 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 8917A9FB5CE
	for <pgsql-performance@postgresql.org>;
	Thu, 12 Apr 2007 18:24:53 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id l3CLOqel005773;
	Thu, 12 Apr 2007 17:24:52 -0400 (EDT)
To: Steve <cheetah@tanabi.org>
cc: PostgreSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: Strangely Variable Query Performance 
In-reply-to: <Pine.GSO.4.64.0704121653030.17955@kittyhawk.tanabi.org> 
References: <57271CC2-BCB1-4ACA-A177-4FF64F1BC33F@brandeis.edu>
	<E1HbzJr-0005VG-GC@elasmtp-curtail.atl.sa.earthlink.net>
	<16E9A17C-ADFA-43B2-B7EA-5C7A4D7E96D1@event-s.net>
	<E1Hc0lc-0001iE-La@elasmtp-banded.atl.sa.earthlink.net>
	<0914C05F-BA1B-4A6C-A1B1-52256BC851A4@event-s.net>
	<1176396964.13754.16.camel@state.g2switchworks.com>
	<Pine.LNX.4.64.0704121000570.32187@glacier.frostconsultingllc.com>
	<Pine.GSO.4.64.0704121653030.17955@kittyhawk.tanabi.org>
Comments: In-reply-to Steve <cheetah@tanabi.org>
	message dated "Thu, 12 Apr 2007 17:03:17 -0400"
Date: Thu, 12 Apr 2007 17:24:52 -0400
Message-ID: <5772.1176413092@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200704/262
X-Sequence-Number: 24139

Steve <cheetah@tanabi.org> writes:
> On a Postgres 8.2.3 server, I've got a query that is running very slow in 
> some cases.

Could we see the exact definition of that table and its indexes?
It looks like the planner is missing the bitmap scan for some reason,
but I've not seen a case like that before.

Also, I assume the restriction on receipt date is very nonselective?
It doesn't seem to have changed the estimated rowcount much.

			regards, tom lane