Re: Minor performance improvement in transition to external sort

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeremy Harris <jgh(at)wizmail(dot)org>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Minor performance improvement in transition to external sort
Date: 2014-02-24 17:38:15
Message-ID: CA+TgmoaC_Lsy=Lituc7qXN4=BLzY+CpWwG85+QOSo_FXR3n0kw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 20, 2014 at 7:27 PM, Jeremy Harris <jgh(at)wizmail(dot)org> wrote:
> On 09/02/14 17:11, Jeremy Harris wrote:
>> On 06/02/14 18:21, Jeff Janes wrote:
>>> Did you try sorting already-sorted, reverse
>>> sorted, or pipe-organ shaped data sets? We will also need to test it on
>>> strings. I usually use md5(random()::text) to generate strings for such
>>> purposes, at least for a first pass.
>>
>>
>> Attached is version 2 of the patch, which fixes the performance on
>> constant-input.
>
> Having beaten on this some more I'm prepared to abandon it.
>
> The wallclock time, for random input, drifts up at larger N
> (compared to the existing code) despite the number of comparisons
> being consistently less.
>
> Run under cachegrind, it takes about N/10 last-level cache misses,
> all for the new item being introduced to the heap. The existing
> code takes none at all.

Can you explain this further? This seems like an important clue that
could be useful when trying to optimize this code, but I'm a little
unclear which part of the operation has more cache misses with your
changes and why.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-02-24 17:45:12 Re: psql should show disabled internal triggers
Previous Message Josh Berkus 2014-02-24 17:31:16 Re: jsonb and nested hstore