Thanks for reply, Alexander.
So, the mapping is the same
Yes,I think mappings are the same (same custom analyzers/filters/number of shards/etc). Both indexes have no "_all" field (it was disabled for ES6, and is not supported in ES7 at all). Both indexes are created using the same JSON payload (provided in gist)
I have only briefly check the comparison, I did not find it intuitive to compare
The last (top) diff here shows the fields on which they are different. Left (red) column is ES6 and right (green) is ES7.
I have used the command POST /documents/_forcemerge?max_num_segments=1 to merge both indexes before making a comparison.
This size seems to stem from a different configuration.
I thought that only index settings can affect index size. But as I mentioned before index settings are the same. Do you know which other settings can impact index size?
While writing this I thought that there can be some changes in default settings. I will investigate it and write the results.
What makes you think the new block max wand feature is causing this?
As well as I understand the article this new feature adds some extra data in index files (which helps to speed up the searching).
These lines from the article makes me think so:
... introduces block-max indexes and block-max WAND. The underlying idea of this paper is to split postings into fixed-size blocks and to record the maximum impact score separately for each block.
... instead of recording impact scores in the index, we record pairs of term frequency and document length.