github-actions[bot] commented on PR #14524:
URL: https://github.com/apache/lucene/pull/14524#issuecomment-2972028702
This PR has not had activity in the past 2 weeks, labeling it as stale. If
the PR is waiting for review, notify the d...@lucene.apache.org list. Thank you
for your contributi
HUSTERGS commented on PR #14524:
URL: https://github.com/apache/lucene/pull/14524#issuecomment-2923052803
> @javanna Hey! I kinda disagree with: `general idea was to make concurrency
as transparent as possible` since the caller thread is used alongside another
exec service. I think trading
Shibi-bala commented on PR #14524:
URL: https://github.com/apache/lucene/pull/14524#issuecomment-2920389497
@javanna Hey! I kinda disagree with: `general idea was to make concurrency
as transparent as possible` since the caller thread is used alongside another
exec service. I think trading
github-actions[bot] commented on PR #14524:
URL: https://github.com/apache/lucene/pull/14524#issuecomment-2906085585
This PR has not had activity in the past 2 weeks, labeling it as stale. If
the PR is waiting for review, notify the d...@lucene.apache.org list. Thank you
for your contributi
javanna commented on PR #14524:
URL: https://github.com/apache/lucene/pull/14524#issuecomment-2865817224
Thanks for clarifying @Shibi-bala .
I get a bit confused here with the mention of query fairness. What #13472
does is advance execution on the caller thread, that would otherwise
Shibi-bala commented on PR #14524:
URL: https://github.com/apache/lucene/pull/14524#issuecomment-2845644300
@javanna I think what users need (or expect) with a TaskExecutor is to be
able to have the created tasks run on the ExecutorService provided by the user.
In my example, I'd like to be
javanna commented on PR #14524:
URL: https://github.com/apache/lucene/pull/14524#issuecomment-2844725328
Having introduced TaskExecutor in the first place and worked quite a bit on
inter-segment concurrency and other ways to parallelize execution, the general
idea was to make concurrency as
Shibi-bala commented on PR #14524:
URL: https://github.com/apache/lucene/pull/14524#issuecomment-2828849510
@jpountz `IMO Lucene should own how queries execute concurrently instead of
making it pluggable` then why allow an executor service to be passed in?
Previously, lucene didn't have con
jpountz commented on PR #14524:
URL: https://github.com/apache/lucene/pull/14524#issuecomment-2827538594
IMO Lucene should own how queries execute concurrently instead of making it
pluggable. So I'd rather not allow users to pass a custom `TaskExecutor`.
--
This is an automated message fr
Shibi-bala commented on PR #14524:
URL: https://github.com/apache/lucene/pull/14524#issuecomment-2822084989
This really only impacts Knn queries where the work is done in rewrite and
indexSearcher.getTaskExecutor() is called from the knn query. For all other
queries, the caller can control
Shibi-bala commented on PR #14524:
URL: https://github.com/apache/lucene/pull/14524#issuecomment-2821765755
@jainankitk ah linked the wrong PR. It was
https://github.com/apache/lucene/pull/13472 that made this change, and it seems
like there were considerable speedups. Though it comes at th
jainankitk commented on PR #14524:
URL: https://github.com/apache/lucene/pull/14524#issuecomment-2820171449
While I am not sure about changing to non-final, I am wondering if we should
execute task on the current thread? Not sure if we save too much overhead and
that makes code less readabl
Shibi-bala opened a new pull request, #14524:
URL: https://github.com/apache/lucene/pull/14524
### Description
The new task executor implementation from
https://github.com/apache/lucene/pull/13861 means users can't control the
parallelism of the tasks being run. I think it is fair to
13 matches
Mail list logo
