jpountz commented on PR #14358: URL: https://github.com/apache/lucene/pull/14358#issuecomment-2727467298
I'm wary about adding all these micro-optimizations to reduce the per-segment per-field overhead. They hurt readability and may easily get lost over time when codecs get replaced with new codecs. Presumably, the motivation is to reduce heap usage when working with lots of shards / segments / fields? Could this be solved differently so that heap usage due to open indexes remains low by design rather than as a result of many micro-optimizations? E.g. by pooling index readers using a least-recently used policy, using a single Lucene field for multiple logical fields (like Elasticsearch's `flattened` does), merging segments more aggressively (e.g. by bumping the floor/min segment size), or a combination of all these things? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
