On Aug 17, 2007, at 5:23 PM, Michael Stone wrote:
On Fri, Aug 17, 2007 at 10:43:18AM +0200, Frank Schoep wrote:
On Aug 17, 2007, at 9:28 AM, hubert depesz lubaczewski wrote:
(cost=0.00..37612.76 rows=14221 width=48) (actual
time=0.125..13.686 rows=2000 loops=1)
[snip]
I'm not an expert at h
On Fri, Aug 17, 2007 at 10:43:18AM +0200, Frank Schoep wrote:
On Aug 17, 2007, at 9:28 AM, hubert depesz lubaczewski wrote:
(cost=0.00..37612.76 rows=14221 width=48) (actual time=0.125..13.686
rows=2000 loops=1)
[snip]
I'm not an expert at how the planner decides which query plan to use,
N
On Aug 17, 2007, at 9:28 AM, hubert depesz lubaczewski wrote:
…
try to change the query to:
SELECT * FROM movies WHERE letter = 'T' ORDER BY letter ASC, name
ASC LIMIT 100
OFFSET 1900;
Thanks for the suggestion, however executing this query takes even
longer regardless of work_mem. The que
On Thu, Aug 16, 2007 at 06:14:02PM +0200, Frank Schoep wrote:
> The (example) query:
> SELECT * FROM movies WHERE letter = 'T' ORDER BY name ASC LIMIT 100
> OFFSET 1900;
try to change the query to:
SELECT * FROM movies WHERE letter = 'T' ORDER BY letter ASC, name ASC LIMIT 100
OFFSET 1900;
d
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 "819
Frank Schoep <[EMAIL PROTECTED]> 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
>
Hello everyone,
This being my first e-mail to the mailing list, I hope my question is
relevant and on-topic. I'm seeing poor performance on a few queries
where the planner decides to use a bitmap scan instead of using indices.
I'm using a stock PostgreSQL 8.1.9 on Debian 4.0r0 (x86). The
