Re: Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Jeremy Harris <jgh(at)wizmail(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"
Date: 2015-08-04 05:41:53
Message-ID: CAMkU=1xx5=ELFe8Lqqn80vU4RO=gH+nEpSYDdp20+NXPuSQ-YQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jul 31, 2015 4:22 AM, "Jeremy Harris" <jgh(at)wizmail(dot)org> wrote:
>
> On 30/07/15 02:05, Peter Geoghegan wrote:
> > Since heapification is now a big fraction of the total cost of a sort
> > sometimes, even where the heap invariant need not be maintained for
> > any length of time afterwards, it might be worth revisiting the patch
> > to make that an O(n) rather than a O(log n) operation [3].
>
> O(n log n) ?
>
> Heapification is O(n) already, whether siftup (existing) or down.

They are both linear on average, but the way we currently do it has an
NlogN worst case, while the other way is linear even in the worst case.

Cheers, Jeff

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-08-04 05:43:29 Re: tablecmds.c and lock hierarchy
Previous Message Michael Paquier 2015-08-04 05:28:56 Re: Minimum tuple threshold to decide last pass of VACUUM