Re: Choice of bitmap scan over index scan - Mailing list pgsql-performance

From Robert Haas
Subject Re: Choice of bitmap scan over index scan
Date
Msg-id 603c8f071001101853p6dd9517bofb7fcef43c97d79e@mail.gmail.com
Whole thread Raw
In response to Re: Choice of bitmap scan over index scan  (Jeremy Harris <jgh@wizmail.org>)
Responses Re: Choice of bitmap scan over index scan
List pgsql-performance
On Sun, Jan 10, 2010 at 9:04 AM, Jeremy Harris <jgh@wizmail.org> wrote:
> On 01/10/2010 12:28 PM, Mathieu De Zutter wrote:
>>
>> Sort  (cost=481763.31..485634.61 rows=1548520 width=338) (actual
>> time=5423.628..6286.148 rows=1551923 loops=1)
>>  Sort Key: event_timestamp
>
>  >  Sort Method:  external merge  Disk: 90488kB
>>
>>  ->  Seq Scan on log_event  (cost=0.00..79085.92 rows=1548520 width=338)
>> (actual time=0.022..2195.527 rows=1551923 loops=1)
>>        Filter: (event_timestamp > (now() - '1 year'::interval))
>> Total runtime: 6407.377 ms
>
> Needing to use an external (on-disk) sort method, when taking
> only 90MB, looks odd.
>
> - Jeremy

Well, you'd need to have work_mem > 90 MB for that not to happen, and
very few people can afford to set that setting that high.  If you have
a query with three or four sorts using 90 MB a piece, and five or ten
users running them, you can quickly kill the box...

...Robert

pgsql-performance by date:

Previous
From: Robert Haas
Date:
Subject: Re: Choice of bitmap scan over index scan
Next
From: Mathieu De Zutter
Date:
Subject: Re: Choice of bitmap scan over index scan