hoice for me? What
other setup/idea I can try?
thanks,
XJ
the query) and it surprised me too. Could it due to we're using many
> complex sortings (20 sortings with dismax, and, or...). Any thing it can be
> optimized? Looks like it's calculated twice in solr?
>
> XJ
>
> --
> View this message in context:
> http://lucen
hm.. just looked at the log only 112 matched, and start=0, rows=30
On Mon, Feb 6, 2012 at 1:33 PM, Yonik Seeley wrote:
> On Mon, Feb 6, 2012 at 3:30 PM, oleole wrote:
> > Thanks for your reply. Yeah that's the first thing I tried (adding
> fsv=true
> > to the query) and it surprised me too. Coul
Yes as I mentioned in previous email, we do dismax queries(with different
mm values), solr function queries (map, etc) math calculations (sum,
product, log). I understand those are expensive. But worst case it should
only double the time not going from 200ms to 1200ms right?
XJ
On Mon, Feb 6
Yonik, thanks for your explanation. I've created a ticket here
https://issues.apache.org/jira/browse/SOLR-3104
On Mon, Feb 6, 2012 at 4:28 PM, Yonik Seeley wrote:
> On Mon, Feb 6, 2012 at 6:16 PM, XJ wrote:
> > Sorry I didn't make this clear. Yeah we use dismax in main
We use fsv=true to help debug sortings which works great for
non-distributed searches. However, its not working (no sort_values in
response) for multi shard queries. Any idea how to get this fixed?
thanks,
XJ
