Re: Berkeley DB...

From: "Matthias Urlichs" <smurf(at)noris(dot)de>
To: Hannu Krosing <hannu(at)tm(dot)ee>
Cc: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'Michael A(dot) Olson'" <mao(at)sleepycat(dot)com>, "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Berkeley DB...
Date: 2000-05-25 13:40:50
Message-ID: 20000525154050.J6744@noris.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)noris(dot)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 babies in the wings, we can count on
being employed until we drop, or get smart and switch to gardening, paper
folding, or something."
-- C. Philip Wood

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-05-25 13:42:48 Re: understanding Datum -> char * -> Datum conversions
Previous Message Chris Bitmead 2000-05-25 13:06:37 gram.y PROBLEM with UNDER