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 ancestors: we borrow it from our
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
from our children, we're
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
from our children, we're
...@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
--
Eliot Gable
We do not inherit the Earth from our ancestors: we borrow it from our
children. ~David Brower
I decided
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
On Thu, Jul 8, 2010 at 9:53 AM, Kevin Grittner
kevin.gritt...@wicourts.govwrote:
Eliot Gable
egable+pgsql-performa...@gmail.comegable%2bpgsql-performa...@gmail.com
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
very well compared to the alternative methods.
On Tue, Jul 6, 2010 at 6:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Eliot Gable
egable+pgsql-performa...@gmail.comegable%2bpgsql-performa...@gmail.com
writes:
Do I need to somehow force the server to unload and then re-load this .so
file each
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
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,
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
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 mmonc...@gmail.com wrote:
On Fri, Jul 2, 2010 at 11:17 PM, Eliot Gable
egable+pgsql-performa...@gmail.com egable%2bpgsql-performa...@gmail.com
...@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 tea leaves
--
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 from
our children, we're stealing from them--and it's not even considered to be a
crime. ~David Brower
Esse oportet
to implement? 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 borrowing from
our children, we're
Just curious if this would apply to PostgreSQL:
http://queue.acm.org/detail.cfm?id=1814327
http://queue.acm.org/detail.cfm?id=1814327Now 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 / sorts
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
?
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 sfr...@snowman.net wrote:
* Eliot Gable
(egable+pgsql-performa...@gmail.comegable%2bpgsql-performa...@gmail.com)
wrote:
Would a query
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 sfr...@snowman.net wrote:
* Eliot Gable
(egable+pgsql-performa...@gmail.comegable%2bpgsql-performa...@gmail.com)
wrote:
Thanks
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, Eliot Gable
egable+pgsql-performa...@gmail.com egable
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 mmonc...@gmail.com wrote:
On Fri, Apr 23, 2010 at 4:42 PM, Eliot Gable
egable+pgsql-performa...@gmail.com egable%2bpgsql-performa...@gmail.com
wrote:
To answer
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 egable%2bpgsql-performa...@gmail.comwrote:
That's a good point. However, even after changing it, it is still 12ms
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 enough to dump any approach that depends on temp tables.
merlin
--
Eliot Gable
We do not inherit the Earth from our ancestors: we borrow
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 decided the words were too conservative for me. We're
, 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. ~David Brower
I decided the words
On Thu, Apr 1, 2010 at 3:01 PM, Faheem Mitha fah...@email.unc.edu 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.
On Thu, Mar 25, 2010 at 10:00 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Mar 23, 2010 at 5:00 PM, Eliot Gable
egable+pgsql-performa...@gmail.com egable%2bpgsql-performa...@gmail.com
wrote:
The complex type contains roughly 25 fields, mostly text, plus another 10
REFCURSORs.
How
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 Earth from our ancestors: we borrow it from our
children. ~David
27 matches
Mail list logo
