> -----Original Message-----
> From: firebird-support@yahoogroups.com
> [mailto:firebird-support@yahoogroups.com] On Behalf Of Ann W. Harrison
> Sent: 1. juni 2005 21:30
> To: firebird-support@yahoogroups.com
> Subject: Re: [firebird-support] Firebird 2.0 Indexing
>
> buppcpp wrote:
> > Were the changes to the indexes in 2.0 suppose to provide more than
> > larger indexes?
>
> Yes, and they do. However, you need to distinguish between
> the different problems you identify as "index performance".
> >
> >
> > Ex. SELECT distinct store_no from mytable; (Does a table scan)
>
> That's not a problem with the index. It's the optimizer that
> decides whether to use an index or not, based on the access
> paths it knows how to create.
>
> As you probably have heard by now, a multi-generational
> record database engine can not resolve queries from the index
> without reference to the actual data records.
> Multi-generational indexes include entries that, from the
> perspective of any given transaction, are not yet committed
> or have been superseded. The only way to know if a record is
> valid for a particular transaction is to read it. Since the
> records have to be checked for validity, and since reading
> records in index order is slower than reading records in
> storage order, a natural scan and sort is the fastest
> (available) access path for this query.
>

Wouldn't it be possible to add transaction information to the index entries
so that the engine doesn't have to lookup the record for validation?

It probably isn't possible but I was just wondering.

/Svend