[PERFORM] C on Client versus C on Server

ve to pull all the data down to the User Client, I must also push the data back up to the server for writing the billing records. So, am I looking at this the right way, or am I missing something? Thanks in advance for any responses. -- Eliot Gable "We do not inherit the Earth from our

Re: [PERFORM] GPU Accelerated Sorting

 it  of course > important for the future. > > Regards, > > -- > Gaël Le Mignot - g...@pilotsystems.net > Pilot Systems - 9, rue Desargues - 75011 Paris > Tel : +33 1 44 53 05 55 - www.pilotsystems.net > Gérez vos contacts et vos newsletters : www.cockpit-mailing.com > --

[PERFORM] GPU Accelerated Sorting

that up to you guys to figure out. http://code.google.com/p/back40computing/wiki/RadixSorting -- Eliot Gable "We do not inherit the Earth from our ancestors: we borrow it from our children." ~David Brower "I decided the words were too conservative for me. We're not bo

[PERFORM] GPU Accelerated Sorting

that up to you guys to figure out. http://code.google.com/p/back40computing/wiki/RadixSorting -- Eliot Gable "We do not inherit the Earth from our ancestors: we borrow it from our children." ~David Brower "I decided the words were too conservative for me. We're not borrowing

Re: [PERFORM] performance on new linux box

On Thu, Jul 8, 2010 at 9:53 AM, Kevin Grittner wrote: > Eliot Gable > > > wrote: > > > For about $2k - $3k, you can get a server that will do upwards of > > 300 MB/sec, assuming the bulk of that cost goes to a good > > hardware-based RAID controller with a bat

Re: [PERFORM] performance on new linux box

me good 15k RPM SAS drives. Since it sounds like you are disk I/O bound, it's probably not worth it for you to spend extra on CPU and memory. Sink the money into the disk array instead. If you have an extra $4k more money in your budget, you might even try 4 of these in a RAID 10: http://www.provantage.com/ocz-technology-oczssd2-2vtxex100g~7OCZT0L9.htm -- Eliot Gable

Re: [PERFORM] Highly Efficient Custom Sorting

ill work very well compared to the alternative methods. On Tue, Jul 6, 2010 at 6:21 PM, Tom Lane wrote: > 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

Re: [PERFORM] Highly Efficient Custom Sorting

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

Re: [PERFORM] Highly Efficient Custom Sorting

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

Re: [PERFORM] Highly Efficient Custom Sorting

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 &

Re: [PERFORM] Highly Efficient Custom Sorting

t up some global variables to do that, or am I supposed to take a different approach? If I need to use global variables, then how do I deal with concurrency? On Sat, Jul 3, 2010 at 2:08 PM, Merlin Moncure wrote: > On Fri, Jul 2, 2010 at 11:17 PM, Eliot Gable > > > wrote: > > Well,

Re: [PERFORM] Highly Efficient Custom Sorting

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 faster > approach to interpretation than PL/PgSQL. > > Really, the right choice depends on exactly what the OP is

Re: [PERFORM] Highly Efficient Custom Sorting

er 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 approache

[PERFORM] Highly Efficient Custom Sorting

ement? What are the drawbacks of each different method? Thanks in advance for your insights. -- Eliot Gable "We do not inherit the Earth from our ancestors: we borrow it from our children." ~David Brower "I decided the words were too conservative for me. We're not bor

[PERFORM] B-Heaps

Just curious if this would apply to PostgreSQL: http://queue.acm.org/detail.cfm?id=1814327 Now that I've read it, it seems like a no-brainer. So, how does PostgreSQL deal with the different latencies involved in accessing data on disk for searches / sort

Re: [PERFORM] PostgreSQL Function Language Performance: C vs PL/PGSQL

that the PL/PGSQL implementation at its heart also uses SPI to perform those executions. Is that a fair statement? On Wed, May 26, 2010 at 12:32 PM, Stephen Frost wrote: > * Eliot Gable > (egable+pgsql-performa...@gmail.com) > wrote: > > Thanks for the quick follow-up. So, you are

Re: [PERFORM] PostgreSQL Function Language Performance: C vs PL/PGSQL

? The function gets called a lot, but not in the same transaction. It is only called once per transaction. On Wed, May 26, 2010 at 12:18 PM, Stephen Frost wrote: > * Eliot Gable > (egable+pgsql-performa...@gmail.com) > wrote: > > Would a query such as this obtain any performance

[PERFORM] PostgreSQL Function Language Performance: C vs PL/PGSQL

I have been Googling for answers on this for a while, and have not been able to find anything satisfactory. Imagine that you have a stored procedure which is currently written using PL/PGSQL. This stored procedure performs lots of long, complex SQL queries (95% SELECT statements, 5% INSERT or UPDA

Re: [PERFORM] Replacing Cursors with Temporary Tables

turned result set), unnesting an array is much faster than building a temp table and selecting from it. If anyone thinks I may have missed some important item in this testing, please let me know. On Fri, Apr 23, 2010 at 8:39 PM, Eliot Gable < egable+pgsql-performa...@gmail.com >wrote

Re: [PERFORM] Replacing Cursors with Temporary Tables

n the same transaction with the same input values, there is no need to inline the function call. On Fri, Apr 23, 2010 at 5:01 PM, Merlin Moncure wrote: > On Fri, Apr 23, 2010 at 4:42 PM, Eliot Gable > > > wrote: > > To answer the question of whether calling a stored procedure adds any

Re: [PERFORM] Replacing Cursors with Temporary Tables

d procedure gets called by itself hundreds or even thousands of times per second on a production system, the nested calls to individual sub-stored procedures would just add extra overhead for no real gain. And, from these tests, it would be significant overhead. On Thu, Apr 22, 2010 at 4:57 PM, Eli

Re: [PERFORM] Replacing Cursors with Temporary Tables

ending on _any_ temporary resources causes plan mgmt > issues because the database detects that a table in the old plan is > gone ('on commit drop') and has to re-plan. If your functions are > complex/long and you are counting milliseconds, then that alone should > be enoug

[PERFORM] Replacing Cursors with Temporary Tables

and a non-inlined function in C? I would greatly appreciate any insights to these questions/issues. Thanks in advance for any assistance anyone can provide. -- Eliot Gable "We do not inherit the Earth from our ancestors: we borrow it from our children." ~David Brower "I decid

Re: [PERFORM] experiments in query optimization

On Thu, Apr 1, 2010 at 3:01 PM, Faheem Mitha wrote: > > So, should I add indexes on the individual foreign key cols idlink_id >>> and anno_id after all? >>> >> >> I doubt that would help. >> > > You're sure of this? > > > It is always best to test and be certain.

Re: [PERFORM] experiments in query optimization

on the foreign key, then the inner scan can be an index scan and that might turn out to be faster than building the hash indexes on all the table rows. Somebody can correct me if I'm wrong. -- Eliot Gable "We do not inherit the Earth from our ancestors: we borrow it from our children.&q

Re: [PERFORM] Performance Tuning Large PL/PGSQL Stored Procedure

On Thu, Mar 25, 2010 at 10:00 PM, Merlin Moncure wrote: > On Tue, Mar 23, 2010 at 5:00 PM, Eliot Gable > > > wrote: > > The complex type contains roughly 25 fields, mostly text, plus another 10 > > REFCURSORs. > > How many rows min/max/avg are coming back in you

[PERFORM] Performance Tuning Large PL/PGSQL Stored Procedure

It currently takes about 45ms to execute the query and retrieve all of the results into the C++ application. Query execution time takes up about 16ms of that 45ms. This is on a 3-year old Core 2 Duo, so it's not exactly top-of-the-line hardware. -- Eliot Gable "We do not inherit the E