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, 2012 at 2:37 PM, Yonik Seeley <yo...@lucidimagination.com>wrote: > On Mon, Feb 6, 2012 at 5:35 PM, XJ <oleol...@gmail.com> wrote: > > hm.. just looked at the log only 112 matched, and start=0, rows=30 > > Are any of the sort criteria sort-by-function with anything complex > (like an embedded relevance query)? > > -Yonik > lucidimagination.com > > > > > > On Mon, Feb 6, 2012 at 1:33 PM, Yonik Seeley <yo...@lucidimagination.com > > > > wrote: > >> > >> On Mon, Feb 6, 2012 at 3:30 PM, oleole <oleol...@gmail.com> wrote: > >> > Thanks for your reply. Yeah that's the first thing I tried (adding > >> > fsv=true > >> > to 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? > >> > >> It currently does calculate it twice... but only for those documents > >> being returned (which should not be significant). > >> What is "rows" set to? > >> > >> -Yonik > >> lucidimagination.com > > > > >
