lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eks Dev (JIRA)" <>
Subject [jira] Commented: (LUCENE-1035) Optional Buffer Pool to Improve Search Performance
Date Mon, 03 Mar 2008 22:02:50 GMT


Eks Dev commented on LUCENE-1035:

you said: 
....We actually have a multiplexing directory that (depending on file type and size), either
opens the file purely in memory, uses a cached file, or lets the OS do the caching. Works
really well...

Did you create a patch somewhere, or is this your internal work?

I have a case where this could come in very handy, I plan to use MMAP for postings & co...
but FSDirectory for stored fields as they could easily blow the size ... With possibility
to to select on file type/size  makes MMAP use case much much closer to many users... one
Directory implementation that allows users to select strategy is indeed perfect, LRU, FSDirectora,
MMAP, RAM or whatnot 

> Optional Buffer Pool to Improve Search Performance
> --------------------------------------------------
>                 Key: LUCENE-1035
>                 URL:
>             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:
For additional commands, e-mail:

View raw message