From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Zeugswetter Andreas SB'" <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'Matthias Urlichs'" <smurf(at)noris(dot)de> |
Cc: | "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Berkeley DB... |
Date: | 2000-05-25 17:14:41 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A23018C04@SECTORBASE1 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > ... 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.
>
> As long as everything fits into the system cache and is
> already in there, this test is moot.
Oh, if we want to test how cache is affected by index-nature of
MySQL-BDB then 10000 rows table is toooo small. It adds just
2 levels of internal pages (including root) and ~25 8k pages
to ~ 190 pages of true heap table: additional pages will be
cached very fast, just while fetching first 25 rows from table -:)
Now create 10000000 rows table (~ 25000 additional pages, 3 internal
levels) and fetch random 10000 rows...
...And again - does MySQL-BDB really read *table* for query like
select a from foo order by a? I remember that MySQL is smart to
read only index when possible...
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Ned Lilly | 2000-05-25 17:36:47 | Re: |
Previous Message | Bruce Momjian | 2000-05-25 17:05:40 | Re: Create user/create database outside template1 |