<blockquote style="margin:0 0 0 40px;border:none;padding:0px"></blockquote><u><i>Or do you mean that it's one number per document whereas the other stats</i><br><i>are per database, so it's harder to store it?</i></u><div>
<br></div><div>yes, I mean this. It's a huge data. If a new doclength list(contains all the doclength in a list, like chert)</div><div>is added by myself, I am concern about:</div><div>1. This doclength list may be the bottlenect in this backend, <a href="http://trac.xapian.org/ticket/326">http://trac.xapian.org/ticket/326</a></div>
<div>2. Change too much above Lucene file format, then it's hard to compare performance between Xapian and Lucene</div><div><br></div><div>Some ideas:</div><div>1. Using rank algorithm without doclength, such as BM25Weight or TradWeight without doclength, or tfidfWeight.</div>
<div>    If ranking results will be not good without doclength?</div><div>2. Stores doclength in .prx payload when doing Lucene indexing. </div><div>    <a href="https://lucene.apache.org/core/3_6_0/api/all/org/apache/lucene/index/Payload.html">https://lucene.apache.org/core/3_6_0/api/all/org/apache/lucene/index/Payload.html</a></div>
<div>    <a href="http://searchhub.org/2009/08/05/getting-started-with-payloads/">http://searchhub.org/2009/08/05/getting-started-with-payloads/</a></div><div>    But this method has obvious drawback, it's not for general Lucene index data, if doclength is not stored, this method</div>
<div>    doesn't works</div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
</blockquote></div>Any suggestions?</div><div><br></div><div>Regards</div>