On Wed, Mar 6, 2013 at 8:08 PM, Emmanuel Espina wrote:
> I understand and it sounds ok. The "store" index would be like an ordinary
> database where you search by value.
>
> Another approach you could consider is to compress the field before
> indexing. That is you compress with
>
> http://docs.or
I understand and it sounds ok. The "store" index would be like an ordinary
database where you search by value.
Another approach you could consider is to compress the field before
indexing. That is you compress with
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/zip/GZIPInputStream.html
and
On Mon, Mar 4, 2013 at 11:26 PM, Emmanuel Espina
wrote:
> 100 terms in a boolean query is not so costly. You could wrap that query in
> a ConstantScoreQuery to avoid the score calculation.
>
Thank you Immanuel. This one sounds good.
>
> Why do you have separate indexes? It would be better to bui
100 terms in a boolean query is not so costly. You could wrap that query in
a ConstantScoreQuery to avoid the score calculation.
Why do you have separate indexes? It would be better to build a single
document and index+store it on a single index.
Thanks
Emmanuel
2013/3/1 Ramprakash Ramamoorthy
On Fri, Mar 1, 2013 at 4:46 PM, Ian Lea wrote:
> Never rely on lucene internal doc ids. Use your own. Lucene searches
> on unique ids are of course very fast.
>
Point taken Ian. So in case I have 100 matching doc Ids and so the next
step is either collate the 100 docIds into a query with OR, o
Never rely on lucene internal doc ids. Use your own. Lucene searches
on unique ids are of course very fast.
--
Ian.
On Fri, Mar 1, 2013 at 9:51 AM, Ramprakash Ramamoorthy
wrote:
> Hello team,
>
> I have a query and I am explaining it as below.
>
> Objective : To split index and sto
