[
https://issues.apache.org/jira/browse/LUCENE-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537978
]
Ning Li commented on LUCENE-1035:
---------------------------------
> Were the tests run using the same set of queries they were warmed for?
Yes, the same set of queries were used. The warm-up and the real run are two
separate runs, which means the file system cache is warmed, but not the buffer
pool.
Yes, it'd much better if a real query log could be obtained. I'll take a look
at the AOL query log. I used to have an intranet query log which has a lot of
term locality. That's why I think this could provide a good improvement.
> There are better ways to optimize for that, e.g., by caching hit lists, no?
That's useful and that's for exact query match. If there are a lot of shared
query term but not exact query match, caching hit list won't help. This is sort
of caching posting list but simpler.
> Optional Buffer Pool to Improve Search Performance
> --------------------------------------------------
>
> Key: LUCENE-1035
> URL: https://issues.apache.org/jira/browse/LUCENE-1035
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Reporter: Ning Li
> Attachments: LUCENE-1035.patch
>
>
> Index in RAMDirectory provides better performance over that in FSDirectory.
> But many indexes cannot fit in memory or applications cannot afford to
> spend that much memory on index. On the other hand, because of locality,
> a reasonably sized buffer pool may provide good improvement over FSDirectory.
> This issue aims at providing such an optional buffer pool layer. In cases
> where it fits, i.e. a reasonable hit ratio can be achieved, it should provide
> a good improvement over FSDirectory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
