At 10:48 AM 12/8/2002 +0100, Arno Brinkman wrote:

>
>I saw that first is called the procedure "VIO_chase_record_version" and
>after that the data is fetched. When we have only an "index-lookup" couldn't
>not just exit after the VIO_chase_record_version? Is there a way that the
>key-data can be different than in the index? I make an test-version and saw
>that there's little speed-up, so maybe interesting enough to look if it
>isn't possible to do with "only-index-lookup".
>

Sorry, but after chasing down the appropriate record version, it's
still necessary to fetch its data and run the expression against it.
And, yes, the key-data can certainly be different from the index
if the index entry belonged to a different version of the index.

>
>With pitty i meant there could be a speed-increment because no data-pages
>had to be accessed for the unneeded data, but as i understand it must be for
>the record_version. Reading a data-page looks a big cost for me.
>

By processing record indirectly through the bitmap, it does guarentee
that a second record on a data page will always find it in cache,
which is worth a lot. But it must fetch and decode the record in
every case.

I took a radically different approach in Netfrastructure. Netfrastructure
caches actual records and the access structure in memory, using a
fairly hairy aging algorithm with garbage collection to maintain a
large but bounded cache. It is also multi-generational, but only
in memory, not on disk. So record references and the equivalent
of VIO_chase_record_version operate purely in memory (after first
reference, of course). The only things that are accessed directly
out of disk cache are index pages, which get no benefit from living
in memory. The net result is that when it's running on a machine
with a hundred buck's worth of memory is that it never touches the
disk.

Jim Starkey