Re: Memory usage during sorting

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <stark(at)mit(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Memory usage during sorting
Date: 2012-03-20 15:29:45
Message-ID: CAMkU=1zsojpLmpz=md4-J2g7S44ZTaHoOqPkx4G16KKYWq67ww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 20, 2012 at 6:31 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <stark(at)mit(dot)edu> writes:
>> Offhand I wonder if this is all because we don't have the O(n) heapify
>> implemented.

I think we do already have it implemented. 1/2 the time the tuple
stays where it is after one comparison, 1/4 it moves up one level with
two comparisons, 1/8 it moves up two levels with 3 comparisons, etc.
That series sums up to a constant. Maybe there is a worst-case that
makes this fall apart, though. Heapifying something which is already
reverse sorted, maybe?

> Robert muttered something about that before, but is it real?  If you
> could do that, I'd think you'd have a less-than-n-log-n sorting
> solution.

Turning random tuples into heap can be linear. Extracting them while
maintaining the heap is NlogN, though. You can't sort without the
extraction step, so the law is preserved.

Cheers,

Jeff

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-03-20 15:43:40 Re: Postgres 8.4 planner question - bad plan, good plan for almost same queries.
Previous Message Greg Stark 2012-03-20 15:24:51 Re: Memory usage during sorting