junegunn commented on PR #8485: URL: https://github.com/apache/hbase/pull/8485#issuecomment-5174106088
Thanks, the updated description reads well. I'd like to ask the original members who started the discussion, but unfortunately, they are no longer active in this project. For unit tests, you might want to check out TestSeekOptimizations. The existing cases seem to compare lazy seeks against eager. They never set a filter though. I also find it hard to come up with a realistic scenario that would actually suffer from the regression, since it depends on several factors at once: - many store files per store - a dataset well beyond the block cache, so seeks actually hit disk - short scans, since the cost is once per scanner open and a long scan amortizes it away - explicit columns and a filter (any filter, not only those implementing `filterRowKey`) Regarding the new configuration property, I don't think we should add a flag to re-introduce a correctness bug unless the performance hit is really unacceptable, and we don't know that yet. But I doubt it is. Out of curiosity: How did you run into this issue? Do you have a production workload that was affected by the bug? If so, what does that workload look like? -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
