>
> I think the answer is that it's faster for interbase to access the records
> in physical order and then sort the results than to access the records in
> emp_no order, which may involve jumping all over the place as
> each record is
> fetched.
>

I thing, it's a bug, it's NO EFFECTIVE.

PLAN SORT mean IB must read all row from table E before can sort the result
! (and I can fetch the first !)
If IB use E NATURAL in join, rows gets accidental order, cache can't extend
P rows, IB must seek each in disk.
If IB use E INDEX ... in join, rows gets order of SQL command, if the first
row joined, it can fetched immediately and if joined tables coming same
order I can use an algorithm named 'interweave'. (for exaple two ordered
file from magnetic tape to a third tape, it's old but good algorithm) These
algorithm good for an intensive cache use too (for example if joined 1:N.,
'N-1' times fired row in cache)

eMeL

sorry my poor english - I can't speak really, what is my idea...

>
> select p.*, e.* from
> employee_project p, employee e
> where p.emp_no = e.emp_no
> order by p.emp_no
> PLAN SORT (JOIN (E NATURAL,P INDEX (RDB$PRIMARY14)))
>
> Firebird 1.0.0.338 for Windows.
>
>