bq: ...and reducing the boost values to much smaller numbers...
not sure why that would matter for performance, muliplying is
multiplying, although reducing the boost on the default field might
have added up to a _lot_ of math ops.
Or is the boosting just a way to change the ranking to something
FYI, think i managed to get the results back and the speeds that i desired
back reducing the number of fields in the qf/pf values from 6 to 4, also
making sure to not boost the default field, and reducing the boost values
to much smaller numbers but still significant enough to boost properly, so
we
Maybe commongrams could help this but it boils down to speed/quality/cheap.
Choose two. Thanks
> On Apr 1, 2017, at 10:28 AM, Shawn Heisey wrote:
>
>> On 3/31/2017 1:55 PM, David Hastings wrote:
>> So I un-commented out the line, to enable it to go against 6 important
>> fields. Afterwards thro
On 3/31/2017 1:55 PM, David Hastings wrote:
> So I un-commented out the line, to enable it to go against 6 important
> fields. Afterwards through monitoring performance I noticed that my
> searches were taking roughly 50% to 100% (2x!) longer, and it started
> at the exact time I committed that cha
Hey all.
I ran into an issue recently. I have a rather large index and in my
application I had defined values for the "pf" parameter, but I had
commented it out years ago not really knowing why I did it. Obviously the
point of the pf helps rank fields higher if they are in close proximity,
and th
