From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
Cc: | "'Michael A(dot) Olson'" <mao(at)sleepycat(dot)com>, "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: AW: Berkeley DB... |
Date: | 2000-05-25 10:14:33 |
Message-ID: | 392CFD09.DDCD5C6E@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Zeugswetter Andreas SB wrote:
>
> > Frankly, based on my experience with Berkeley DB, I'd bet on mine.
> > I can do 2300 tuple fetches per CPU per second, with linear scale-
> > up to at least four processors (that's what we had on the box we
> > used). That's 9200 fetches a second. Performance isn't going
> > to be the deciding issue.
>
> Wow, that sounds darn slow. Speed of a seq scan on one CPU,
> one disk should give you more like 19000 rows/s with a small record size.
> Of course you are probably talking about random fetch order here,
> but we need fast seq scans too.
Could someone test this on MySQL with bsddb storage that should be out
by now ?
Could be quite indicative of what we an expect.
> (10 Mb/s disk, 111 b/row, no cpu bottleneck, nothing cached ,
> Informix db, select count(*) ... where notindexedfield != 'notpresentvalue';
> Table pages interleaved with index pages, tabsize 337 Mb
> (table with lots of insert + update + delete history) )
>
> Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB | 2000-05-25 10:29:41 | AW: AW: SQL3 UNDER |
Previous Message | Zeugswetter Andreas SB | 2000-05-25 10:12:49 | AW: AW: Postgresql OO Patch |