On 7/25/07, Luis Neves <[EMAIL PROTECTED]> wrote:
Yonik Seeley wrote:
> On 7/25/07, Luis Neves <[EMAIL PROTECTED]> wrote:
>> This turn out to be a bad idea ... for some reason using the
>> BoostQuery instead
>> of the BoostFunction slows the search to a crawl.
>
> Dismax throws bq in with the main query, so it can't really be cached
> separately, so iterating over the number of terms in [* TO
> NOW/DAY-3MONTH] for each query is expensive.
Ok.
> You could try lowering the resolution of EntryDate to lower the number
> of unique terms (but that would require reindexing). That would speed
> up a range query, or lower the memory usage of the FieldCache entry.
>
> Solr could also somehow be smarter about the FieldCache and only cache
> the ordinal and not the actual values (this could apply to sorting
> too). Lucene's FieldCache doesn't currently support that though, so
> it would require some hacking.
>
> If you didn't want date math, date faceting, or date ranges, you could
> simply store a date as a classic integer (number of seconds since
> epoch). function queries would still work on this, and the FieldCache
> would be 4 bytes per doc.
I will do a combination of both, I will add a new int field to the index and use
it to hold the number of weeks since epoch (week resolution is good enough for
freshness in our case).
For type "integer" (indexed as straight text... not "sint"), the
FieldCache values are stored directly into the int[] array (instead of
being indexes into a string array), so lowering the resolution to
weekly won't make a difference in memory (it will be 4 bytes per doc
regardless), but *will* speed up first-time generation of this number.
-Yonik
