Subject | Re: [ib-support] Re: using inclusive indices |
---|---|
Author | Ann W. Harrison |
Post date | 2002-11-26T14:32:22Z |
At 05:57 AM 11/26/2002 +0000, mikeevteev wrote:
so they often contain entries that are not valid for all transactions.
The only way to verify that the data is valid for your transaction
is to read the actual record. That being the case, the fastest way
to read all the records in the table is to start with the first data
page and go forward, in other words, NATURAL.
neglected to include?
Regards,
Ann
www.ibphoenix.com
We have answers.
>Table is ... just a table. Nothing special, just a lot of char fields.Firebird indexes reflect the multi-generational data representation,
>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.
so they often contain entries that are not valid for all transactions.
The only way to verify that the data is valid for your transaction
is to read the actual record. That being the case, the fastest way
to read all the records in the table is to start with the first data
page and go forward, in other words, NATURAL.
>Another question related to optimazer.Beats me. Did your query have an order by clause that you
>Table is same.
>Query select field_a from table
>Optimizer plan SORT(table NATURAL).
>
>Why SORT? Here is index already. All fields is covered!
neglected to include?
Regards,
Ann
www.ibphoenix.com
We have answers.