Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: Bad planner decision - bitmap scan instead of index
- From: Frank Schoep <frank(at)ffnn(dot)nl>
- To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
- Cc: pgsql-performance(at)postgresql(dot)org
- Subject: Re: Bad planner decision - bitmap scan instead of index
- Date: Thu, 16 Aug 2007 21:25:14 +0200
On Aug 16, 2007, at 7:01 PM, Tom Lane wrote:
… Why is the sort step so slow? Sorting a mere 13k rows shouldn't take very long. Maybe you are overrunning work_mem and it's falling back to a disk sort ... what is work_mem set to?
By default work_mem is set to "1024". Increasing the value to "8192" halves the execution time, still leaving a factor twenty-five performance decrease compared to using the index. The machine I'm testing this on is a very modest Pentium 3 at 450 MHz.
Another theory is that you are using a locale in which strcoll() is horridly expensive :-(
Running 'locale' indicates I'm using "en_US.UTF-8" with language "en_NL:en". My databases all use the UTF8 encoding.
Sincerely, Frank
- References:
- Bad planner decision - bitmap scan instead of index
- From: Frank Schoep
- Re: Bad planner decision - bitmap scan instead of index
- From: Tom Lane
- Bad planner decision - bitmap scan instead of index
- Prev by Date: Re: Integrated perc 5/i
- Next by Date: Re: Integrated perc 5/i
- Previous by thread: Re: Bad planner decision - bitmap scan instead of index
- Next by thread: Re: Bad planner decision - bitmap scan instead of index
- Indexes: