Hi Jim,

> >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.

Okey, very clear.

> >
> >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.

Sounds nice :-)

Have you an idea what could be done in speeding-up JOINs (index-related)? Is
the maximum speed already there? (I guess so else would you do it in a other
way, but you never know)

Jim & Pavel, Thanks for your information.

Regards,
Arno