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
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 |