[
https://issues.apache.org/jira/browse/LUCENE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-5914:
--------------------------------
Attachment: LUCENE-5914.patch
Some updates:
* port to trunk apis (i guess this was outdated?)
* fix some javadoc bugs
* nuke lots of now-unused stuff in .compressing, only still used for term
vectors
* improve float/double compression: it was not so effective and wasteful. these
now write 1..5 and 1..9 bytes.
We should try to do more cleanup:
* I don't like the delegator. maybe its the best solution, but at least it
should not write its own file. I think we should revive SI.attributes
(properly: so it rejects any attribute puts on dv updates) and use that.
* The delegator shouldnt actually need to delegate the writer? If i add this
code, all tests pass:
{code}
final StoredFieldsWriter in = format.fieldsWriter(directory, si, context);
if (true) return in; // wrapper below is useless
return new StoredFieldsWriter() {
{code}
This seems to be all about delegating some manual file deletion on abort() ? Do
we really need to do this? If we have some bugs around indexfiledeleter where
it doesn't do the right thing, enough to warrant such apis, then we should have
tests for it. Such tests would also show the current code deletes the wrong
filename:
{code}
IOUtils.deleteFilesIgnoringExceptions(directory, formatName); // formatName is
NOT the file the delegator writes
{code}
But this is obselete if we add back SI.attributes.
* The header check logic should be improved. I don't know why we need the
Reader.checkHeader method, why cant we just check it with the other files?
* We should try to use checkFooter(Input, Throwable) for better corruption
messages, with this type of logic. It does more an appends suppressed
exceptions when things go wrong:
{code}
try (ChecksumIndexInput input =(...) {
Throwable priorE = null;
try {
// ... read a bunch of stuff ...
} catch (Throwable exception) {
priorE = exception;
} finally {
CodecUtil.checkFooter(input, priorE);
}
}
{code}
* Any getChildResources() should return immutable list: doesn't seem to always
be the case. Maybe assertingcodec can be improved to actually test this
automatically.
I will look more tomorrow.
> More options for stored fields compression
> ------------------------------------------
>
> Key: LUCENE-5914
> URL: https://issues.apache.org/jira/browse/LUCENE-5914
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Fix For: 5.0
>
> Attachments: LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch
>
>
> Since we added codec-level compression in Lucene 4.1 I think I got about the
> same amount of users complaining that compression was too aggressive and that
> compression was too light.
> I think it is due to the fact that we have users that are doing very
> different things with Lucene. For example if you have a small index that fits
> in the filesystem cache (or is close to), then you might never pay for actual
> disk seeks and in such a case the fact that the current stored fields format
> needs to over-decompress data can sensibly slow search down on cheap queries.
> On the other hand, it is more and more common to use Lucene for things like
> log analytics, and in that case you have huge amounts of data for which you
> don't care much about stored fields performance. However it is very
> frustrating to notice that the data that you store takes several times less
> space when you gzip it compared to your index although Lucene claims to
> compress stored fields.
> For that reason, I think it would be nice to have some kind of options that
> would allow to trade speed for compression in the default codec.
--
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
