Thanks for pointing out the mistake in postgres.
Your Advice makes lots of sense.
V Murali
- Original Message -
From: Cees Hek [EMAIL PROTECTED]
To: Murali V [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, April 20, 2001 1:45 AM
Subject: [OT] Re: Fast DB access
On Thu, 19 Apr
On Thu, 19 Apr 2001, Murali V wrote:
Hi,
If you read the code more deeply, you'll find that the timeit is only
wrapped around select and not around insert.
We've written the insert code so that in the first round you can populate
the database.
You comment out the insert code after the
at www.diffsoft.com
- Original Message -
From: Cees Hek [EMAIL PROTECTED]
To: Murali V [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, April 20, 2001 1:45 AM
Subject: [OT] Re: Fast DB access
On Thu, 19 Apr 2001, Murali V wrote:
Hi,
If you read the code more deeply, you'll
On 18 Apr 2001 08:49:38 -0700, clayton cottingham wrote:
Matthew Kennedy wrote:
On 17 Apr 2001 18:24:43 -0700, clayton wrote:
i wanted a good benchmark for postgres and mysql
{i hope to transpose the sql properly!}
This is a good comparison of MySQL and PostgreSQL 7.0:
Matthew Kennedy wrote:
This might help too:
http://www.angelfire.com/nv/aldev/pgsql/GreatBridge.html
Of course benchmarks are so debatable anyway..
Matt
i saw those they are pretty good
but greatbridge is tied into postgres
somehow
im looking for impartial benchmarks
nonetheless i
On 18 Apr 2001, Clayton Cottingham aka drfrog wrote:
[drfrog]$ perl fast_db.pl
postgres
16 wallclock secs ( 0.05 usr +0.00 sys = 0.05 CPU) @ 400.00/s (n=20)
mysql
3 wallclock secs ( 0.07 usr +0.00 sys = 0.07 CPU) @ 285.71/s (n=20)
postgres
17 wallclock secs ( 0.06 usr +
