From: Tom Lane <tgl@sss.pgh.pa.us>
To: Frank Schoep <frank@ffnn.nl>
Cc: pgsql-performance@postgresql.org
Subject: Re: Bad planner decision - bitmap scan instead of index
Date: Thu, 16 Aug 2007 13:01:24 -0400
Message-ID: <6237.1187283684@sss.pgh.pa.us> (raw)
In-Reply-To: <D9BD2209-87AD-4DA9-ACC9-D013A56FE7FA@ffnn.nl>
References: <D9BD2209-87AD-4DA9-ACC9-D013A56FE7FA@ffnn.nl>
Frank Schoep <frank@ffnn.nl> writes:
> Limit (cost=4002.04..4002.29 rows=100 width=48) (actual
> time=1469.565..1470.097 rows=100 loops=1)
> -> Sort (cost=3997.29..4031.18 rows=13556 width=48) (actual
> time=1460.958..1467.993 rows=2000 loops=1)
> Sort Key: name
> -> Bitmap Heap Scan on movies (cost=86.45..3066.90
> rows=13556 width=48) (actual time=20.522..77.889 rows=13640 loops=1)
> Recheck Cond: (letter = 'T'::bpchar)
> -> Bitmap Index Scan on movies_letter
> (cost=0.00..86.45 rows=13556 width=0) (actual time=18.452..18.452
> rows=13658 loops=1)
> Index Cond: (letter = 'T'::bpchar)
> Total runtime: 1474.821 ms
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?
Another theory is that you are using a locale in which strcoll() is
horridly expensive :-(
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, frank@ffnn.nl
Subject: Re: Bad planner decision - bitmap scan instead of index
In-Reply-To: <6237.1187283684@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox