Re: Choice of bitmap scan over index scan

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeremy Harris <jgh(at)wizmail(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Choice of bitmap scan over index scan
Date: 2010-01-11 02:53:37
Message-ID: 603c8f071001101853p6dd9517bofb7fcef43c97d79e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Sun, Jan 10, 2010 at 9:04 AM, Jeremy Harris <jgh(at)wizmail(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mathieu De Zutter 2010-01-11 08:36:40 Re: Choice of bitmap scan over index scan
Previous Message Robert Haas 2010-01-11 02:52:25 Re: Choice of bitmap scan over index scan