From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] bitmap scan issues 8.1 devel |
Date: | 2005-08-17 21:54:36 |
Message-ID: | 17374.1124315676@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
"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.
(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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-08-17 22:07:18 | Re: gettime() - a timeofday() alternative |
Previous Message | Thomas Hallgren | 2005-08-17 21:54:31 | Re: pl/Ruby, deprecating plPython and Core |
From | Date | Subject | |
---|---|---|---|
Next Message | John A Meinel | 2005-08-17 22:02:28 | Re: Insert performance (OT?) |
Previous Message | Josh Berkus | 2005-08-17 21:33:15 | Re: [HACKERS] bitmap scan issues 8.1 devel |