Re: LIMIT/SORT optimization - Mailing list pgsql-patches

From Gregory Stark
Subject Re: LIMIT/SORT optimization
Date
Msg-id 877it1mxhc.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: LIMIT/SORT optimization  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: LIMIT/SORT optimization  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-patches
"Heikki Linnakangas" <heikki@enterprisedb.com> writes:

> Some comments on the patch below.

Thanks!

> Gregory Stark wrote:
>
>
>
> The comment claims that we use heap sort when the user says he doesn't want to
> use glibc's qsort. I recall that we always use our own qsort implementation
> nowadays. And we never used the heap sort as a qsort replacement, did we?

Thanks, I had a version that used heap sort instead of qsort but that was
before I discovered what you said. So I stripped that useless bit out.

> In performsort, you convert the in-memory heap to a sorted list in one go. I
> wonder if it would be better to switch to a new TSS_ALLINHEAP state that means
> "all tuples are now in the in-memory heap", and call tuplesort_heap_siftup in
> gettuple.

The problem is that the heap is backwards. The head of the heap is the
greatest, ie, the last element we want to return. Hm, Is there such a thing as
a two-way heap?

> There's a few blocks of code surrounded with "#if 0 - #endif". Are those just
> leftovers that should be removed, or are things that still need to finished and
> enabled?

Uhm, I don't remember, will go look, thanks.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com


pgsql-patches by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: [HACKERS] Full page writes improvement, code update
Next
From: Alvaro Herrera
Date:
Subject: Re: autovacuum: multiple workers