Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of msokolov@safaribooksonline.com
 designates 209.85.216.176 as permitted sender)
Message-ID: <54B51772.8090306@safaribooksonline.com>
Date: Tue, 13 Jan 2015 08:02:42 -0500
From: Michael Sokolov <msokolov@safaribooksonline.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: java-user@lucene.apache.org
Subject: Re: howto: handle temporal visibility of a document?
References: <c29c43d32a6a4653a21c4512b1bad423@Exchange2013.mysigndomain.corp>
In-Reply-To: <c29c43d32a6a4653a21c4512b1bad423@Exchange2013.mysigndomain.corp>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org