>> > yes we have the option to override the default NULLs placement, but in this way no index will be used
>> > for sorting :(
>>
>> I actually don't see why the index would not work in those cases, but
>> that could depend on the implementation

>actually FB2.1.3 and FB2.1.4 index it's not used and cannot be specified in the plan :(

I think (i.e. I'm not sure, so test things rather than just believe what I write to be true) that an index for sorting would only be benefitial for returning the first rows and that when returning the entire result set it is slower than using NATURAL. I would not even be surprised if using an index could be slower to return the first rows if there were lots of NULLs in the field in question.

Of course, the best thing is to have a WHERE or JOIN clause that reduces the result set significantly - and for that purpose indexes are brilliant.

If you want an index to be used for sorting, have you tried creating an expression index with NULLS LAST? I kind of see an index ordered with NULLS LAST as different from NULLS FIRST and that different indexes would have to be used. Does it still avoid using the index?

HTH,
Set