Hi Gili,
I responded last time you asked this:
http://lucene.markmail.org/thread/svun5cdtgiy4hnjg
Maybe you are not subscribed to the list?
Mike McCandless
http://blog.mikemccandless.com
On Sat, Jan 26, 2013 at 7:45 AM, Gili Nachum <gilinac...@gmail.com> wrote:
> Hi,
>
> I have a search workload that focuses on two fields in my 1GB index. I get
> very good performance when loaded the index via MMapDirectory. I attribute
> this performance to the Operating System File System (FS OS) cache, that
> keeps the most recently used FS blocks RAM resident.
>
> *I would like to add 50 more fields to the index, increasing it size to
> ~50GB, A key factor is that these additional fields will be queried very
> rarely.
> Given this increase in index size, should I expect lower Queries/Sec rate
> for the original search workload (that doesn't use the new fields)?*
>
> I would assume that if the values of each searchable field are stored in a
> different set of FS blocks, then the 50 additional fields would make no
> difference for the OS FS cache, as it would continue to behave like before,
> keeping in RAM those most used FS blocks.
> On the other hand, if values from different fields share the same FS
> blocks, then the hot 2 fields values will be to scattered across the FS the
> OS cache useless. degradating performance back to I/O bounded.
>
> Which is the case with Lucene 3.6?
>
> Thanks.
> Gili Nachum.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
