From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
Cc: | Eliot Gable <egable+pgsql-performance(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Highly Efficient Custom Sorting |
Date: | 2010-07-02 04:08:50 |
Message-ID: | 4767.1278043730@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Craig Ringer <craig(at)postnewspapers(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michal Fapso | 2010-07-02 05:23:21 | Re: big data - slow select (speech search) |
Previous Message | Tom Lane | 2010-07-02 04:05:04 | Re: No hash join across partitioned tables? |