Re: [PERFORM] bitmap scan issues 8.1 devel
От | Merlin Moncure |
---|---|
Тема | Re: [PERFORM] bitmap scan issues 8.1 devel |
Дата | |
Msg-id | 6EE64EF3AB31D5448D0007DD34EEB3417DD121@Herge.rcsinc.local обсуждение исходный текст |
Список | pgsql-hackers |
> "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. 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
В списке pgsql-hackers по дате отправления: