Re: Berkeley DB...

Поиск
Список
Период
Сортировка
От Matthias Urlichs
Тема Re: Berkeley DB...
Дата
Msg-id 20000525154050.J6744@noris.de
обсуждение исходный текст
Ответ на Re: AW: Berkeley DB...  (Hannu Krosing <hannu@tm.ee>)
Список 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 по дате отправления:

Предыдущее
От: Chris Bitmead
Дата:
Сообщение: gram.y PROBLEM with UNDER
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: understanding Datum -> char * -> Datum conversions