Ordering of lf.op.or match args sets order of results when column is indexed

[simon-weber]

I've found a pretty specific bug. For a query like or(col.match, col.match...).orderBy(col), if col is indexed, then the ordering of the results are defined by the ordering of or's arguments instead of orderBy.

Here's an example: https://jsfiddle.net/qnfywync/1/ (code also at https://gist.github.com/simon-weber/e9ac8147b5daaf1ca08fdae0ec55cad2). I've marked the spots that are interesting to change with a -->.

Superficially, this looks similar to #118 -- maybe the issue is also with MultiColumnOrPass?

[freshp86]

Thanks for the report. I can reproduce this. The example has a small error (num is stored as a number because parseInt(i,10) is called (it should be i.toString() instead), but I can still reproduce without it.

[freshp86]

So, I have identified the problem within the OrderByIndexPass. The initial query plan is

project()
-order_by(Item.num ASC)
--select(combined_pred_or)
---table_access(Item)

After the OrderByIndexPass is applied, the execution plan is modified as follows

project()
-select(combined_pred_or)                                                                                                                                                                                       
--table_access_by_row_id(Item)
---index_range_scan(Item.idxDesc, [unbound, unbound], natural)

The results are sorted correctly using the available index, up until the select(combined_pred_or) step is executed which discards the sort order up to that point and uses the order in which the OR terms appear in the query. I am still thinking about the proper fix. My initial thinking is that the OrderByIndexPass should be updated to not modify the tree when an OR predicate exists, because the tree after modification is not equivalent to the original tree.