Kjell Rilbe wrote:

>> that keeps it from walking an index?
>
> Well, if there are indexes on STOCK.ID and proveedores.id, these indexes
> *could* be used to sort each stream and do a sorted merge to produce the
> union stream. I assume it would be faster than doing a natural, append
> one stream to the other and then sort the whole thing, which I assume
> Firebird is doing according to the quoted plan.
>
> But Firebird doesn't do sorted merges I guess?
>

Yes it does, but not by navigational access to two indexes in a union.
When a query can't be resolved by a series of indexed nested loops,
Firebird will build up partial result sets, then sort and merge them.
I think current optimizer can also recognize other cases when a sort
merge is the best method, but I think it doesn't do that in this case.


Cheers,

Ann