In article <4098d412$0$12740$afc38c87_at_news.optusnet.com.au>, Howard J.
Rogers says...
> In your specific first question, your query A1 can be
> answered entirely from within the index (which are invariably going to
> be smaller than the tables they're built on, and hence take less I/O to
> scan). But as soon as you introduce the new column, you're going to have
> to visit the table anyway, and your query is selecting all rows from the
> table, so you're going to have to visit all of it anyway. Well, if
> you're going to have to visit all of the table regardless, why take a
> detour to an index in the first place?
>
Thanks for your response there Howard. But in table A we are not
necessarily going to be reading every row - it is restricted by the rows
in table B - so we might say that all rows from table B would need to be
read but only those rows which *match* from table A need to be read -
perhaps I should have made it clearer that the 'description' column is
actually on table A.
--
jeremy
Received on Wed May 05 2004 - 08:54:22 CDT
