Re: Highly Efficient Custom Sorting - Mailing list pgsql-performance

From Tom Lane
Subject Re: Highly Efficient Custom Sorting
Date
Msg-id 4767.1278043730@sss.pgh.pa.us
Whole thread Raw
In response to Re: Highly Efficient Custom Sorting  (Craig Ringer <craig@postnewspapers.com.au>)
Responses Re: Highly Efficient Custom Sorting
List pgsql-performance
Craig Ringer <craig@postnewspapers.com.au> writes:
> On 02/07/10 08:46, Eliot Gable wrote:
>> So, the bottom line is, I need a faster way to do this sorting.

> You haven't showed us how you're doing it at the moment, so it's awfully
> hard to comment usefully on possible approaches.

I'm guessing from tea leaves, but the impression I got from Eliot's
description is that he's using plpgsql functions as sort comparators.
It's not surprising that that sucks performance-wise compared to having
the equivalent logic in C/C++ functions used as comparators on the
client side.  plpgsql is no speed demon.  Best fix might be to code the
comparators as C functions on the server side.

            regards, tom lane

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: No hash join across partitioned tables?
Next
From: Michal Fapso
Date:
Subject: Re: big data - slow select (speech search)