| From: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PERFORM] bitmap scan issues 8.1 devel |
| Date: | 2005-08-18 12:18:32 |
| Message-ID: | 6EE64EF3AB31D5448D0007DD34EEB3417DD121@Herge.rcsinc.local |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ali Baba | 2005-08-18 14:46:01 | Re: transactions not working properly ? |
| Previous Message | Qingqing Zhou | 2005-08-18 09:14:02 | Re: SHM_LOCK under Linux ... do we use this? |