[
https://issues.apache.org/jira/browse/LUCENE-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-6863:
---------------------------------
Attachment: LUCENE-6863.patch
Here is an updated patch that makes the sparse impl a bit more efficient when
consumed in sequential order by keeping track of the upper bound of the current
window. This is what has been used in the above benchmark.
I also updated the heuristic to require 1024 docs in the segment and that less
than 1% of docs have a value in order to be on the safe side and to only slow
down abuse/exceptionnal cases. Even if/when this gets used for some fields, I
think the slowdown is acceptable insofar as it would only slow down fast
queries: if you look at the above benchmarks, when the query matches many docs
(such as a MatchAllDocsQuery) this encoding is actually faster than regular
delta encoding. Only queries that match a small partition of the index (so that
most dv lookups will require a binary search) would become slower.
Opinions?
> Store sparse doc values more efficiently
> ----------------------------------------
>
> Key: LUCENE-6863
> URL: https://issues.apache.org/jira/browse/LUCENE-6863
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Attachments: LUCENE-6863.patch, LUCENE-6863.patch
>
>
> For both NUMERIC fields and ordinals of SORTED fields, we store data in a
> dense way. As a consequence, if you have only 1000 documents out of 1B that
> have a value, and 8 bits are required to store those 1000 numbers, we will
> not require 1KB of storage, but 1GB.
> I suspect this mostly happens in abuse cases, but still it's a pity that we
> explode storage requirements. We could try to detect sparsity and compress
> accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
