Re: Highly Efficient Custom Sorting

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Highly Efficient Custom Sorting
Дата
Msg-id AANLkTim90VO9XeZ25XjhbhLjhATVlx6CCQRLDhm24GOL@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Highly Efficient Custom Sorting  (Matthew Wakeling <matthew@flymine.org>)
Список pgsql-performance
On Fri, Jul 2, 2010 at 10:50 AM, Matthew Wakeling <matthew@flymine.org> wrote:
>> On Fri, Jul 2, 2010 at 12:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>
>>> 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.
>
> On Fri, 2 Jul 2010, Eliot Gable wrote:
>>
>> I guess the real question is, is a generic C sorting function my only real
>> alternative?
>
> Sounds to me like you are not really listening. You don't need to code an
> entire sorting algorithm in C, as Postgres already has a pretty good one of
> those. All you need to do is implement a comparator of some kind. Inserting
> C functions into Postgres is pretty easy, especially on the level of
> comparators.

in recent versions of postgres you rarely if ever even have to do that
-- row types are comparable w/o any extra work, as are arrays.  If
Eliot would just give a little more deal of WHAT he is trying to sort
and HOW he is currently doing it, i suspect his problem will be
trivially solved :-).

merlin

В списке pgsql-performance по дате отправления:

Предыдущее
От: Matthew Wakeling
Дата:
Сообщение: Re: Highly Efficient Custom Sorting
Следующее
От: Ranga Gopalan
Дата:
Сообщение: Question about partitioned query behavior