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 по дате отправления: