Nice investigation Mike! Your observation about it doing multiple block decodes is one reason why I chose BinaryDocValues in SOLR-5170 to use one byte[] for a pair of numbers. In Karl's last email he remarked this was still only 20% faster than looking up a pair of NumericDocValues; I suspect moving to Memory DVFormat will help more.
~ David From: "Michael McCandless-2 [via Lucene]" <ml-node+s472066n4094143...@n3.nabble.com<mailto:ml-node+s472066n4094143...@n3.nabble.com>> Date: Tuesday, October 8, 2013 2:31 PM To: "Smiley, David W." <dsmi...@mitre.org<mailto:dsmi...@mitre.org>> Subject: Re: FW: Is there a really performant way to store a full 32-bit int in doc values? … So, ~46% faster: ~405 msec vs 592 msec You should be able to do even better with a custom DVFormat, because even forcing 32 bits per value, it's still doing block decode, so every get must first find the block then lookup value within the block. Mike McCandless http://blog.mikemccandless.com ----- Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/Re-Is-there-a-really-performant-way-to-store-a-full-32-bit-int-in-doc-values-tp4094150.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
