Erick Erickson wrote
> So you're saying that you have B_1 - B_8 in one doc, B_9 - B_16 in
> another doc etc?
Well yes that could work, but this would mean we get a lot of unique dymanic
fields, basically equal to the number of documents in our system and I am
not sure if that is a good practice.
So you're saying that you have B_1 - B_8 in one doc, B_9 - B_16 in
another doc etc?
What's so confusing is that in your first e-mail, you said:
bq: This denormalization grows the index size with a factor 100 in worse case.
Which I took to mean you have at most 100 of these fields.
Please look at
Erick Erickson wrote
> Well, you're constructing the URL somewhere, you can choose the right
> boost there can't you?
Yes of course!
As example:
We have one filter field called FILTER which can have unlimited values acros
all documents.
Each document as on average 8 values set for FILTER (e.g.
bq: But it is possible to select a different boost field depending on
the current filter query?
Well, you're constructing the URL somewhere, you can choose the right
boost there can't you?
I don't understand this bit:
Well its basically one multivalued field that can have unlimited
values and has
Erick Erickson wrote
>
> So why not index these boosts in separate fields in the document (e.g.
> f1_boost, f2_boost etc) and use a function query
> (https://cwiki.apache.org/confluence/display/solr/Function+Queries) at
> query time to boost by the correct one?
Well its basically one multivalued
Hmmm, I scanned your question, so maybe I missed something. It sounds
like you have a fixed number of filters known at index time, right? So
why not index these boosts in separate fields in the document (e.g.
f1_boost, f2_boost etc) and use a function query
(https://cwiki.apache.org/confluence/disp