Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] bitmap scan issues 8.1 devel

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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

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

			regards, tom lane

In response to

pgsql-performance by date

Next:From: John A MeinelDate: 2005-08-17 22:02:28
Subject: Re: Insert performance (OT?)
Previous:From: Josh BerkusDate: 2005-08-17 21:33:15
Subject: Re: [HACKERS] bitmap scan issues 8.1 devel

pgsql-hackers by date

Next:From: Jim C. NasbyDate: 2005-08-17 22:07:18
Subject: Re: gettime() - a timeofday() alternative
Previous:From: Thomas HallgrenDate: 2005-08-17 21:54:31
Subject: Re: pl/Ruby, deprecating plPython and Core

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group