> "Merlin Moncure" <[EMAIL PROTECTED]> 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.
You nailed it...I hard coded the limit and everything was cool. In fact, the same problem contributes to the fact that I've had to run seqscan=false on all my production systems. It seemed the planner would randomly seqscan the table...now I know why. > (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?) I absolutely support this :) In normal usage, the supplied limit is quite small, say 100 or less. Anyways, planner issues aside, parameterizing the limit is an elegant way to read records off a table when you don't know how many you are going to read in advance...I make heavy use of it :(. Merlin ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
