X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id AED4A52AAE;
	Wed, 17 Aug 2005 18:54:39 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 77510-04; Wed, 17 Aug 2005 21:54:34 +0000 (GMT)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by svr1.postgresql.org (Postfix) with ESMTP id 455E052A7E;
	Wed, 17 Aug 2005 18:54:33 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j7HLsa0t017375;
	Wed, 17 Aug 2005 17:54:36 -0400 (EDT)
To: "Merlin Moncure" <merlin.moncure@rcsonline.com>
Cc: pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] bitmap scan issues 8.1 devel 
In-reply-to: <6EE64EF3AB31D5448D0007DD34EEB3417DD11C@Herge.rcsinc.local> 
References: <6EE64EF3AB31D5448D0007DD34EEB3417DD11C@Herge.rcsinc.local>
Comments: In-reply-to "Merlin Moncure" <merlin.moncure@rcsonline.com>
	message dated "Wed, 17 Aug 2005 16:40:34 -0400"
Date: Wed, 17 Aug 2005 17:54:36 -0400
Message-ID: <17374.1124315676@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006]
X-Spam-Level: 
X-Archive-Number: 200508/218
X-Sequence-Number: 13965

"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> Doing some testing on upcoming 8.1 devel and am having serious issues
> with new bitmap index scan feature.  It is easy to work around (just
> disable it) but IMO the planner is using it when a regular index scan
> should be strongly favored.

I think blaming the bitmap code is the wrong response.  What I see in
your example is that the planner doesn't know what the LIMIT value is,
and accordingly is favoring a plan that isn't going to get blown out of
the water if the LIMIT is large.  I'd suggest not parameterizing the
LIMIT.

(But hmm ... I wonder if we could use estimate_expression_value for
LIMIT items, instead of handling only simple Consts as the code does
now?)

			regards, tom lane