Thanx Dmitry

It does wonders for my perception of the Firebird project when the
main developer takes time to answer my mundane questions. Thank you
very much! I'm an even bigger disciple now.

I notice that if I drop the ImportBatchId from the key that the plan
changes to:

PLAN (IMPORTBPDATA ORDER IBD_KEYF5 INDEX (IBD_KEYLINENO))

My main reason for wanting the ID with the key is to use it to drive a
header click sort app that is limited by ID. I am not however seeing a
major increase in performance for this applicaation if I get the above
plan.

I'm conviced that a index that can act as a both a selector and
sequence must be a lot faster (no sort to do) - I will test when this
functionality has been included and report back here.

Regards

Chris

--- In firebird-support@yahoogroups.com, "Dmitry Yemanov" <dimitr@...>
wrote:

>
> "chrisacron" <chris@...> wrote:
> >
> > mmmmm This is on a LI-V2.0.0.12691 Firbird 2.0 Release Candidate 3
> > server running in Linux Superserver. So the plan is still not what I
> > expected.
>
> Is the database in ODS11? I.e. has it been restored on FB2?
>
> > You say: "The current optimizer cannot use the same index for both
> > retrieval and sorting..."
> >
> > This surpises me and would account for the re-ordering delays as it
> > reads everything and sorts it - which it won't have to if it read the
> > records in the correct sequnce to start off with.
>
> It depends on what do you need to perform fast. A SORT plan is usually
> faster to fetch the entire ordered set whilst an ORDER plan is faster to
> deliver you the first rows.
>
> > Do you know if there are any plans to change the optimiser to use the
> > same key for retrieval and sorting - it would make the world of
> > difference.
>
> Yes, such an improvement will appear in the next FB version.
>
>
> Dmitry
>