Actually I sat down and read more about compound file format.
Basically, instead of creating several files representing a single segment, the compound format creates a single file for the whole segment.
And you can have a mix of compound and non compound segments for a given index. So you can set different settings for transactional and batch in theory. Not sure why though.
Compounds Pro:
- less file handlers
Compounds Con:
- slower at indexing
- takes temporarily more space on disk as the uncompound segment is converted to a compound segment when done
I don't think this affects the incremental copy so much are segments are essentially read-only.
I believe this is not the story we tell to people in the doc, so we need to fix that.
On Nov 11, 2008, at 10:07, Emmanuel Bernard wrote:
It seems that a few parameters should not be configurable per transaction|batch
- use_compound_file
- max_field_length? not sure
- term_index_interval (is that a config influencing IndexReader?)
What do you think?
I am a bit worried to stick them as is in the project / book as they are right now.
Let's try and sort this out today.
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev