On 1/13/2015 2:07 AM, Clemens Wyss DEV wrote:
reduced to:
( ( *:* -visiblefrom:[* TO *] AND -visibleto:[* TO *] )
OR (-visiblefrom:[* TO *] AND visibleto:[<now in ms> TO <long max
value>])
OR (-visibleto:[ * TO *] AND visiblefrom:[0 TO <now in ms>])
OR ( visiblefrom:[0 TO <now in ms>] AND visibleto:[ <now in ms> TO <long
max value>]) )
also if you index an explicit null value you won't need them at all
Could it then be reduced to
(-visiblefrom:[* TO *] AND visibleto:[<now in ms> TO <long max value>])
OR (-visibleto:[ * TO *] AND visiblefrom:[0 TO <now in ms>])
OR ( visiblefrom:[0 TO <now in ms>] AND visibleto:[ <now in ms> TO <long
max value>])
?
Would I gain a lot more speed if I set visiblefrom to 0 and visibleto to <long
max value>. The query would then be:
visiblefrom:[0 TO <now in ms>] AND visibleto:[ <now in ms> TO <long max value>]
I don't know how much, but I'm pretty sure you would gain some - you'd
need to measure to be sure.
And a rather Solr'y question, nevertheless I ask it here:
I intended to use this very query as query filter (qf), but I guess it doesn't make
sense because '<now in ms>' changes at every call ;)
You could reduce the granularity and cache for a short period of time? I
believe the range query is more efficient with coarser resolution as
well, so if you can handle hour- or minute- precision instead of ms,
there might be some gain. But all these performance questions are only
worth asking in the context of the rest of your application. You might
gain 20% (wild guess) on this part of the query, but if it is 1% of the
overall workload, it's not worth worrying about.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
