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
>
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
Eliot Gable 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 pgsql-performance mailing list (pgsql-perfo
On Tue, Jul 6, 2010 at 4:17 PM, Eliot Gable <
egable+pgsql-performa...@gmail.com >wrote:
>
> On Tue, Jul 6, 2010 at 4:00 PM, Joe Conway 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 simple
On Tue, Jul 6, 2010 at 4:00 PM, Joe Conway 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, there are also
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 lin
On Tue, Jul 6, 2010 at 3:01 PM, Robert Haas wrote:
> On Sat, Jul 3, 2010 at 4:17 PM, Eliot Gable
> >
> 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
On Sat, Jul 3, 2010 at 4:17 PM, Eliot Gable
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 through the documentation on how
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 f
On Sat, Jul 3, 2010 at 4:17 PM, Eliot Gable
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 where each group
> is treated separ
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
complexi
On Fri, Jul 2, 2010 at 11:17 PM, Eliot Gable
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 Perl code on the
> sorting. I won't
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
m
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 fast
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 o
On Fri, Jul 2, 2010 at 10:50 AM, Matthew Wakeling wrote:
>> On Fri, Jul 2, 2010 at 12:08 AM, Tom Lane 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 suck
On Fri, Jul 2, 2010 at 12:08 AM, Tom Lane 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++ functio
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
On Thu, Jul 1, 2010 at 8:46 PM, Eliot Gable
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 just 15.2ms, which is
> very impres
Craig Ringer 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 imp
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: http://soapyfrogs.blogspot.co
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 r
22 matches
Mail list logo
