Hi Luigi, (I am a co-worker of Hung, the original author of this post)
Thank you very much for your answer. Creating the following index really improved the performance of that query (without @rid in ORDER BY clause). CREATE INDEX Task.PriorityDueTime ON Task (Priority, DueTime) NOTUNIQUE We tried that solution in the past, but it doesn't work because we were doing *ORDER BY Priority DESD, DueTime ASC*, and with that mixed ordering direction this solution does not work. We can also achieve our target with *ORDER BY Priority **DESD**, DueTime * *DESC*, so your answer is valid for us. Thank you very much again. David. El miércoles, 4 de mayo de 2016, 11:48:09 (UTC+2), Luigi Dell'Aquila escribió: > > Hi, > > The problem here is that the result set can be sorted using the index when > you define ORDER BY Priority DESC, but when you add other conditions like > ORDER BY Priority DESC, @rid ASC then the index becomes useless and the > result set has to be sorted in memory. > For the second case (ORDER BY Priority DESC, DueTime DESC) you can define > a composite index on Priority and DueTime, this should speed up the query a > lot. > When @rid is involved in general, indexes are not helpful, because the rid > cannot be indexed in current release > > Thanks > > Luigi > > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
