[
https://issues.apache.org/jira/browse/LUCENE-5321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812089#comment-13812089
]
Shai Erera commented on LUCENE-5321:
------------------------------------
I'll add the test back with the assumeTrue. I'm not sure where to document this
FacetCodec example ... it doesn't seem to belong in any of the classes'
javadocs, and package.html aren't too verbose (point to blogs). So maybe we can
just write a blog about it, though really, this isn't too complicated to figure
out. I'll attach a patch shortly, want to make sure this test + assume really
work!
> Remove Facet42DocValuesFormat
> -----------------------------
>
> Key: LUCENE-5321
> URL: https://issues.apache.org/jira/browse/LUCENE-5321
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
> Reporter: Shai Erera
> Attachments: LUCENE-5321.patch
>
>
> The new DirectDocValuesFormat is nearly identical to Facet42DVF, except that
> it stores the addresses in direct int[] rather than PackedInts. On
> LUCENE-5296 we measured the performance of DirectDVF vs Facet42DVF and it
> improves perf for some queries and have negligible effect for others, as well
> as RAM consumption isn't much worse. We should remove Facet42DVF and use
> DirectDVF instead.
> I also want to rename Facet46Codec to FacetCodec. There's no need to refactor
> the class whenever the default codec changes (e.g. from 45 to 46) since it
> doesn't care about the actual Codec version underneath, it only overrides the
> DVF used for the facet fields. FacetCodec should take the DVF from the app
> (so e.g. the facet/ module doesn't depend on codecs/) and be exposed more as
> a utility Codec rather than a real, versioned, Codec.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
