You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Robert Muir (JIRA)" <ji...@apache.org> on 2013/08/08 19:25:48 UTC

[jira] [Updated] (LUCENE-5159) compressed diskdv sorted/sortedset termdictionaries

     [ https://issues.apache.org/jira/browse/LUCENE-5159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Muir updated LUCENE-5159:
--------------------------------

    Attachment: LUCENE-5159.patch

Here's an in-progress patch... all the core/codec tests pass, but I'm sure there are a few bugs to knock out (improving the tests is the way to go here).

I'm also unhappy with the complexity.

The idea is for the variable case, we just prefix-share (i set interval=16), like lucene 3.x dictionary. The current patch specializes the termsenum and reverselookup for this case (but again, im sure there are bugs, its hairy)
                
> compressed diskdv sorted/sortedset termdictionaries
> ---------------------------------------------------
>
>                 Key: LUCENE-5159
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5159
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: core/index
>            Reporter: Robert Muir
>         Attachments: LUCENE-5159.patch
>
>
> Sorted/SortedSet give you ordinal(s) per document, but them separately have a "term dictionary" of all the values.
> You can do a few operations on these:
> * ord -> term lookup (e.g. retrieving facet labels)
> * term -> ord lookup (reverse lookup: e.g. fieldcacherangefilter)
> * get a term enumerator (e.g. merging, ordinalmap construction)
> The current implementation for diskdv was the simplest thing that can possibly work: under the hood it just makes a binary DV for these (treating ordinals as document ids). When the terms are fixed length, you can address a term directly with multiplication. When they are variable length though, we have to store a packed ints structure in RAM.
> This variable length case is overkill and chews up a lot of RAM if you have many unique values. It also chews up a lot of disk since all the values are just concatenated (no sharing).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org