Skip site navigation (1) Skip section navigation (2)

AW: AW: Berkeley DB...

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Zeugswetter Andreas SBDate: 2000-05-25 16:02:06
Subject: AW: AW: AW: SQL3 UNDER
Previous:From: Ed LoehrDate: 2000-05-25 15:51:23
Subject: vacuum analyze feedback

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group