| From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
|---|---|
| To: | "'Michael A(dot) Olson'" <mao(at)sleepycat(dot)com> |
| Cc: | "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | AW: AW: Berkeley DB... |
| Date: | 2000-05-25 15:56:15 |
| Message-ID: | 219F68D65015D011A8E000006F8590C604AF7DA7@sdexcsrv1.f000.d0188.sd.spardat.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > 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.
>
> The test was random reads on a 250GB database. I don't have a
> similar characterization for sequential scans off the top of my
> head.
Yes, for random access this timing sounds better. Was that timing taken with
access through a secondary index or through the recnum ?
Did you make sure that nothing was cached, not even the recnum index ?
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zeugswetter Andreas SB | 2000-05-25 16:02:06 | AW: AW: AW: SQL3 UNDER |
| Previous Message | Ed Loehr | 2000-05-25 15:51:23 | vacuum analyze feedback |