[jira] [Commented] (OAK-4887) Query cost estimation: ordering by an unindexed property not reflected

["Thomas Mueller (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16290508#comment-16290508 ] 

Thomas Mueller commented on OAK-4887:
-------------------------------------

> we can remove the sort hack from lucene index planner now

[~catholicon] Yes, I think it should be removed. But not now yet. It should be removed once we have added the query hint to favor fast first row versus fast retrieval of all rows. Similar to "fastfirstrow" option / "option (fast <n>)" in MS SQL Server (see my comment above). I think "option (fast 1)" should be the default, and to favor a non-sorting index you would have to use "option (fast 10000)" or so (to optimize for the case where you always read 10000 nodes).

> I think its still better that a index-based-sort gets preferred over in-mem sort done by query engine because even getting the first row for in-mem-sort case requires loading the whole result set. 

Yes, that means the query engine would prefer "option (fast 1)". I think that makes sense. Queries that read many rows are rare.

> Query cost estimation: ordering by an unindexed property not reflected
> ----------------------------------------------------------------------
>
>                 Key: OAK-4887
>                 URL: https://issues.apache.org/jira/browse/OAK-4887
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: query
>    Affects Versions: 1.4.2
>            Reporter: Alexander Klimetschek
>            Assignee: Thomas Mueller
>             Fix For: 1.7.12, 1.8
>
>
> A query that orders by an unindexed property seems to have no effect on the cost estimation, compared to the same query without the order by, although it has a big impact on the execution performance for larger results/indexes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)