From: Thomas H. <tho...@t-...> - 2003-03-31 21:45:55
|
> > ... > > Now create an index index1 on testid and do a select distinct testid. > > This will give on my machine (fb1.5b4) ~ 1sec, plan sort table1 natural > > As already said, I'm not sure how selecting is done and I also don't > > know if selecting is possible over the indextree but as the select only > > returns values of the index, wouldn't it be much faster to go over > > the indextree? > > I know this is a very simple view but maybe it could improve things > > much for such things as presenting the user a distinct value listbox > > (selected distinct from one column of a table) from which he may > > then set a filter? > > > I think that for every value found in the index, Fb/IB would need to check > the actual records to see whether they (at least one) can be 'seen' by your > transaction. So, instead of hunting down most/all records according to the > index it just scans the table once. > Shouldn't the indexes also be uptodate at the moment the transaction starts? I would assume that this should be true otherwise how could Indexes then do their work if they wouldn't be uptodate? Assuming the above I'm still curious why indexes could not be used as 'data'? Maybe I miss something? Regards Thomas |