Subject | Re: using inclusive indices |
---|---|
Author | mikeevteev |
Post date | 2002-11-26T05:57:33Z |
Hi!
Table is ... just a table. Nothing special, just a lot of char fields.
Main point is it has index, lets say on field named field_a.
Query is stupid of cource: select field_a from table
I just guess that reading index is cheaper then reading all data pages
in that case, becouse index cover all fields in query.
But optimizer select plan with natural.
Another question related to optimazer.
Table is same.
Query select field_a from table
Optimizer plan SORT(table NATURAL).
Why SORT? Here is index already. All fields is covered!
Table is ... just a table. Nothing special, just a lot of char fields.
Main point is it has index, lets say on field named field_a.
Query is stupid of cource: select field_a from table
I just guess that reading index is cheaper then reading all data pages
in that case, becouse index cover all fields in query.
But optimizer select plan with natural.
Another question related to optimazer.
Table is same.
Query select field_a from table
Optimizer plan SORT(table NATURAL).
Why SORT? Here is index already. All fields is covered!
--- In ib-support@y..., Raymond Kennington <progsol@c...> wrote:
> mikeevteev wrote:
> >
> > Hi all!
> >
> > I trying understand why FB 1.0 doesn't use inclusove indices.
> >
> > I have simple plains selec field from table, and that field has
index.
> > But plan shouws me full table scan.
> >
> > Whats up? How I can force FB use index?
> >
> > If put plan statent it gives me error that I cant use that index
for
> > this query. But that is ridiculous!
> >
> > Mike
> >
>
> What is the table declaration?
>
> What is the query?
> --
> Raymond Kennington
> Programming Solutions
> W2W Team B