lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan McKinley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2649) FieldCache should include a BitSet for matching docs
Date Wed, 22 Sep 2010 19:33:34 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913734#action_12913734
] 

Ryan McKinley commented on LUCENE-2649:
---------------------------------------

bq. more performant too (and avoid more synchronizing lookups)

This was my motivation for putting it all together and using the options as part of the key.
 But yes, inconsistent usage will eat up RAM.  That is better then my original fear that inconsistent
usage would give you unpredictable results!

Also, with the current Cache implementaion, we would need to somehow be able to add two cache
entries from within Cache.createEntry() -- either rewrite all that or hack in some way to
pass the FieldCache to the createEntry method.

Keeping the values and bits in different cache entries is pretty ugly (especially for the
normal case where we want them both all the time)
{code:java}
    return new ByteValues() {
      (byte[])caches.get(Byte.TYPE).get(reader, new Entry(field, parser??)),
      (Bits)caches.get(Byte.TYPE).get(reader, new Entry(field, parser??)),
    };
{code}


bq. But we could probably still achieve these two benefits while using a single class for
looking up everything "cached" about a field? Ie, the CachedArray could return non-null bits
but null values?

Brainstorming here...  if Parser -> EnteryCreator and the 'EntryCreator.hashCode()' is
used as the map key (as it is now)

{code:java}
  public abstract class EntryCreator implements Serializable {
    public boolean cacheValidBits() {
      return false;
    }
    public boolean cacheValues() {
      return true;
    }
  }
{code}

The trick would be to use the same *key* regardless of what we ask for (values but no bits
- bits but no values - bits and values, etc) and then fill up whatever is missing if it is
not in the existing cache.

That might suggest that the 'class' could be the key, but setting the cacheValidBits/values
would need to get implemented by inheratance, so that is out.

other ideas?  directions I am not thinking about?






> FieldCache should include a BitSet for matching docs
> ----------------------------------------------------
>
>                 Key: LUCENE-2649
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2649
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Ryan McKinley
>             Fix For: 4.0
>
>         Attachments: LUCENE-2649-FieldCacheWithBitSet.patch, LUCENE-2649-FieldCacheWithBitSet.patch,
LUCENE-2649-FieldCacheWithBitSet.patch, LUCENE-2649-FieldCacheWithBitSet.patch, LUCENE-2649-FieldCacheWithBitSet.patch
>
>
> The FieldCache returns an array representing the values for each doc.  However there
is no way to know if the doc actually has a value.
> This should be changed to return an object representing the values *and* a BitSet for
all valid docs.

-- 
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message