From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannu(at)skype(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: has anyone looked at burstsort ? |
Date: | 2007-07-13 14:24:50 |
Message-ID: | 21307.1184336690@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)skype(dot)net> writes:
> has anyone looked at burstsort
> https://sourceforge.net/projects/burstsort
> they claim that "Copy-Burstsort is a sorting algorithm for strings that
> is cache-efficient.
If its reason for living is cache efficiency, then I wonder
(1) how well does it work on data types other than strings, or for
that matter even strings when the comparison function is strcoll()
rather than memcmp(). A heavyweight comparison function is likely
to play hob with any assumptions about memory access patterns.
(2) does it scale to deal with problems larger than memory (ie,
how do you make it spill to disk).
> if the speed claim is true, and there are no other bad effects, like for
> example very bad memory use, we could try to talk the author into
> allowing us to include it under BSD licens (currently it is GPL)
If we wrote our own implementation ... and realistically, fitting it
into postgres would likely require rewriting much of the code anyway
... then we don't have to worry about the copyright on someone else's
implementation. What we do have to worry about is whose patent(s)
we might be infringing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-07-13 14:29:16 | Re: has anyone looked at burstsort ? |
Previous Message | Zdenek Kotala | 2007-07-13 13:58:17 | Re: compiler warnings on the buildfarm |