Open ryneeverett opened 4 years ago
@lenormf Any thoughts on this proposal? TLDR: I don't think unlimited search_threads_rebuild_limit is an ideal default but it seems that limiting by time is more helpful and relativizes the limitation so that a reasonable default can be chosen.
I don't think using time as a metric explicitly is a good thing:
Thanks for the feedback.
I believe this approach better addresses the variability of preferences by removing the variability of performance as a source of disagreement. The current default blocks for several minutes for me and is presumably nothing for you. Consider this an argument. :)
As for redundancy, my proposal is to eliminate the count limit setting. Furthermore, assuming a user did want a 3 second timeout, if they had multiple machines they have to configure them differently to accommodate different performance specs.
If performance is a concern I can do some testing with different approaches but I probably wont expend the effort unless or until performance is the only concern. If I'm correct in my belief that this feature will break alot out of the box for many users, I can't see performance as a compelling reason to reject this change.
Resolve #1518. The problem that search_threads_rebuild_limit tries to solve is UI responsiveness, so the relevant thing to limit is time, not loops.
Next steps if this approach is accepted: