: Worst case scenario (and most frequent) my DisMax queries are using up
: to 5 query fields (qf) with different boosts associated with them. They
: are also have up to 4 phrase fields (pf) to boost if terms are found
: close to each other. The minimum match (mm) is varying from 1 to 100%.

so assuming your field names are an average for 10 characters long, each 
field boost is a number about 2 chars long, and your user input is an 
average of 7 characters long (numbers i'm just randomly pulling out of 
thin air) a standard query string (not on the default field) would be 
10+1+7=18 chars, while a dismax string would be (5+1+2+1)*(5+4)=81 chars 
... 18/81 is amazingly almost the exact the same ratio as what you saw 
between the memory size for a standard query and a dismax query.  (i swear 
i didn't pick those numbers to make it work out that way)

but on to the real question of using string keys instead of Query objects 
as keys...

: So, if there is no canonical representation, than shouldn't the original
: query URL be enough to reproduce the query, as well as act as a cache
: key? I do see some overhead in parsing the query again, but that should

the query cache is a more granular cache then that ... there might be 
multiple queries executed by any one handler, and each get cached 
independently.  custom handlers might even have behavior which isn't 
deterministic based on the URL (i've got some that use params to pick a 
doc in the index, and that doc contains metadata which then drives 
additional queries -- the metadata doc might change even if the URL 
didn't)

If you want caching at a granularity of hte URL as a string, putting an 
HTTP "accelerator" cache (aka: "proxy cache" or "reverse cache proxy") in 
front of solr might be more along the lines of what you are looking for.



-Hoss

Reply via email to