Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-07 Thread Eliot Gable
Thanks again for all the input and suggestions from people. I have this sorting algorithm re-implemented in C now and it is somewhere 2ms to run it now; though it is difficult to get a more accurate measure. There may be some additional optimizations I can come up with, but for now, this will work

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-07 Thread Kenneth Marshall
Hi Eliot, Would you mind posting your code for reference. It is nice to have working examples when trying to figure out how it all fits together. Regards, Ken On Wed, Jul 07, 2010 at 03:23:12PM -0400, Eliot Gable wrote: Thanks again for all the input and suggestions from people. I have this

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-06 Thread Robert Haas
On Sat, Jul 3, 2010 at 4:17 PM, Eliot Gable egable+pgsql-performa...@gmail.com wrote: Read RFC 2782 on random weighted load balancing of SRV records inside DNS. It may be asking a bit much to expect people here to read an RFC to figure out how to help you solve this problem, but... I've looked

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-06 Thread Eliot Gable
On Tue, Jul 6, 2010 at 3:01 PM, Robert Haas robertmh...@gmail.com wrote: On Sat, Jul 3, 2010 at 4:17 PM, Eliot Gable egable+pgsql-performa...@gmail.com egable%2bpgsql-performa...@gmail.com wrote: Read RFC 2782 on random weighted load balancing of SRV records inside DNS. It may be asking a

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-06 Thread Joe Conway
On 07/06/2010 12:42 PM, Eliot Gable wrote: Thanks for suggesting array_unnest(). I think that will actually prove more useful to me than the other example I'm using for extracting my data from an array. I was actually planning on computing the order on the first call and storing it in a linked

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-06 Thread Eliot Gable
On Tue, Jul 6, 2010 at 4:00 PM, Joe Conway m...@joeconway.com wrote: This approach works, but you could also use the SFRM_Materialize mode and calculate the entire result set in one go. That tends to be simpler. See, for example crosstab_hash() in contrib/tablefunc for an example. FWIW,

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-06 Thread Eliot Gable
On Tue, Jul 6, 2010 at 4:17 PM, Eliot Gable egable+pgsql-performa...@gmail.com egable%2bpgsql-performa...@gmail.comwrote: On Tue, Jul 6, 2010 at 4:00 PM, Joe Conway m...@joeconway.com wrote: This approach works, but you could also use the SFRM_Materialize mode and calculate the entire

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-06 Thread Tom Lane
Eliot Gable egable+pgsql-performa...@gmail.com writes: Do I need to somehow force the server to unload and then re-load this .so file each time I build a new version of it? If so, how do I do that? Start a new database session. regards, tom lane -- Sent via

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-03 Thread Merlin Moncure
On Fri, Jul 2, 2010 at 11:17 PM, Eliot Gable egable+pgsql-performa...@gmail.com wrote: Well, I re-wrote the algorithm in Perl. However, it did not solve the speed issue. Running time now is a whopping 240+ ms instead of the 31.8ms I was getting before (15.2 of which is sorting). Here is the

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-03 Thread Eliot Gable
Read RFC 2782 on random weighted load balancing of SRV records inside DNS. That algorithm is what I need implemented, but with an extension. I have groups of records I need to have the algorithm applied to where each group is treated separately from the others. I understand the operational

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-03 Thread Merlin Moncure
On Sat, Jul 3, 2010 at 4:17 PM, Eliot Gable egable+pgsql-performa...@gmail.com wrote: Read RFC 2782 on random weighted load balancing of SRV records inside DNS. That algorithm is what I need implemented, but with an extension. I have groups of records I need to have the algorithm applied to

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-03 Thread Alvaro Herrera
Excerpts from Merlin Moncure's message of sáb jul 03 18:53:46 -0400 2010: What about my suggestion doesn't work for your requirements? (btw, let me disagree with my peers and state pl/perl is lousy for this type of job, only sql/and pl/sql can interact with postgresql variables natively for

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-02 Thread Merlin Moncure
On Thu, Jul 1, 2010 at 8:46 PM, Eliot Gable egable+pgsql-performa...@gmail.com wrote: I have a long stored procedure (over 3,000 lines). Originally, it would take about 44ms to run the whole query. After lots and lots of tweaking, Postgres now runs the entire thing and gathers my results in

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-02 Thread Eliot Gable
Yes, I have two pl/pgsql functions. They take a prepared set of data (just the row id of the original results, plus the particular priority and weight fields) and they return the same set of data with an extra field called order which contains a numerical order to apply when sorting the rows. One

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-02 Thread Matthew Wakeling
On Fri, Jul 2, 2010 at 12:08 AM, Tom Lane t...@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

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-02 Thread Merlin Moncure
On Fri, Jul 2, 2010 at 10:50 AM, Matthew Wakeling matt...@flymine.org wrote: On Fri, Jul 2, 2010 at 12:08 AM, Tom Lane t...@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

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-02 Thread Craig James
On 7/2/10 6:59 AM, Eliot Gable wrote: Yes, I have two pl/pgsql functions. They take a prepared set of data (just the row id of the original results, plus the particular priority and weight fields) and they return the same set of data with an extra field called order which contains a numerical

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-02 Thread Craig Ringer
On 03/07/10 00:36, Craig James wrote: Perl itself is written in C, and some of it's operations are extremely fast. The same is true of PL/PgSQL, though ;-) The main advantage of PL/Perl is that it doesn't rely on the SPI to do everything. It's interpreted not compiled, but it has a much

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-02 Thread Eliot Gable
Well, I re-wrote the algorithm in Perl. However, it did not solve the speed issue. Running time now is a whopping 240+ ms instead of the 31.8ms I was getting before (15.2 of which is sorting). Here is the Perl code on the sorting. I won't post the pl/pgsql code, because this is far more clear (in

[PERFORM] Highly Efficient Custom Sorting

2010-07-01 Thread Eliot Gable
I have a long stored procedure (over 3,000 lines). Originally, it would take about 44ms to run the whole query. After lots and lots of tweaking, Postgres now runs the entire thing and gathers my results in just 15.2ms, which is very impressive given the hardware this is running on. Now, I used to

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-01 Thread Craig Ringer
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. -- Craig Ringer Tech-related writing:

Re: [PERFORM] Highly Efficient Custom Sorting

2010-07-01 Thread Tom Lane
Craig Ringer cr...@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