Sort speed asc vs desc - is desc slower?

[Michael Ryan <mr...@moreover.com>]

When sorting a TrieLongField, should there be any expected difference in query speed when sorting ascending vs sorting descending? I'm seeing desc queries sometimes take 10x longer than asc queries. I can provide more details if necessary.

-Michael

RE: Sort speed asc vs desc - is desc slower?

[Michael Ryan <mr...@moreover.com>]

> Perhaps if there are a lot more ties on one end vs the other?
> Or of the values being sorted on aren't that random?  Do they naturally increase like a timestamp?

It's a unique id field. The id is a simple sequential id, so docs with a lower doc id will naturally also have a lower id.

I think the priority queue would explain it. I'll do some profiling to see if this is it...

-Michael

Re: Sort speed asc vs desc - is desc slower?

[Yonik Seeley <yo...@lucidworks.com>]

On Wed, Dec 12, 2012 at 5:49 PM, Michael Ryan <mr...@moreover.com> wrote:
> When sorting a TrieLongField, should there be any expected difference in query speed when sorting ascending vs sorting descending? I'm seeing desc queries sometimes take 10x longer than asc queries. I can provide more details if necessary.

Perhaps if there are a lot more ties on one end vs the other?
Or of the values being sorted on aren't that random?  Do they
naturally increase like a timestamp?

Docs will collect in the order that the document was indexed
(roughly... things can change somewhat due to out-of-order segment
merges).
So if you sort by a timestamp descending (timestamp when you added the
doc), documents collected later will normally be more competitive than
any documents collected thus far in the priority queue, causing a lot
of flux in said queue.  For the ascending case, the first N documents
you collect are likely to have the lowest timestamp and hence the
priority queue will never change again - it's the optimal case.

-Yonik
http://lucidworks.com