Re: Berkeley DB... - Mailing list pgsql-hackers

From Matthias Urlichs
Subject Re: Berkeley DB...
Date
Msg-id 20000525154050.J6744@noris.de
Whole thread Raw
In response to Re: AW: Berkeley DB...  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
Hi,

Hannu Krosing:
> 
> Could someone test this on MySQL with bsddb storage that should be out
> by now ?
> 
As long as the BDB support in mysql doesn't even remotely come close to
running their own benchmark suite, I for one will not be using it for
any kind of indicative speed test...

... that being said (and I took a quick test with 10000 randomly-inserted
records and fetched them in index order) if the data's in the cache, the
speed difference is insignificant. 

I did this:

create table foo (a int not null,b char(100));
create index foo_a on foo(a);
for(i=0; i<10000; i++) {   insert into foo(a,b) values( `((i*3467)%10000)` , 'fusli');
}
select a from foo order by a;


Times for the insert loop:
14   MySQL-MyISAM
23   PostgreSQL (no fsync)
53   MySQL-BDB (with fsync -- don't know how to turn it off yet)

The select:
0.75  MySQL-MyISAM
0.77  MySQL-BDB
2.43  PostgreSQL

I'll do a "real" test once the BDB support in MySQL is stable enough to
run the MySQL benchmark suite.

Anyway, this quick and dirty test seems to show that BDB doesn't
slow down data retrieval.


NB, the select loop was using an index scan in all cases.

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.       |        http://smurf.noris.de/
-- 
"If the vendors started doing everything right, we would be out of a job.Let's hear it for OSI and X!  With those
babiesin the wings, we can count onbeing employed until we drop, or get smart and switch to gardening, paperfolding, or
something."--C. Philip Wood
 


pgsql-hackers by date:

Previous
From: Chris Bitmead
Date:
Subject: gram.y PROBLEM with UNDER
Next
From: Bruce Momjian
Date:
Subject: Re: understanding Datum -> char * -> Datum conversions