| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | Gunnar Nick Bluth <gunnar(dot)bluth(at)pro-open(dot)de>, Petr Praus <petr(at)praus(dot)net>, Marcos Ortiz <mlortiz(at)uci(dot)cu>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries |
| Date: | 2012-11-05 17:59:12 |
| Message-ID: | CAGTBQpY-976TKn1Gx53WSPYsjaWOtuTurPywR7Doasji_6cPXA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, Nov 5, 2012 at 2:40 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> On Mon, Nov 5, 2012 at 2:09 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>>>> In my experience when doing sorts in isolation, having more work_mem
>>>> is a bad thing, unless it enables you to remove a layer of
>>>> tape-merging. I always blamed it on the L1/L2 etc. levels of caching.
>>>
>>> Blame it on quicksort, which is quite cache-unfriendly.
>>
>> The observation applies to heap sort.
>
> Well, heapsort is worse, but quicksort is also quite bad.
Here[0], an interesting analysis. I really believe quicksort in PG
(due to its more complex datatypes) fares a lot worse.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Claudio Freire | 2012-11-05 20:28:31 | Re: Constraint exclusion in views |
| Previous Message | Claudio Freire | 2012-11-05 17:40:31 | Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries |