[
https://issues.apache.org/jira/browse/IMPALA-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16959268#comment-16959268
]
Tim Armstrong commented on IMPALA-8964:
---------------------------------------
If we set it to a higher value, say > 5s was also need to go through and make
sure that filter sending gets retried and that the query can't get stuck if
filters get dropped.
I looked at partitioned-hash-join-builder.cc and coordinator.cc and it seems
like the filter gets disabled and sent out in the cases where the FPP is too
high or the coordinator is OOM, so we wouldn't have to worry about getting
stuck in those cases.
But it looks like RPC failures are a problem at the moment.
IMPALA-7984 refactors some relevant code.
> Increase runtime filter wait timeout for mt_dop
> -----------------------------------------------
>
> Key: IMPALA-8964
> URL: https://issues.apache.org/jira/browse/IMPALA-8964
> Project: IMPALA
> Issue Type: Sub-task
> Components: Distributed Exec
> Reporter: Tim Armstrong
> Assignee: Tim Armstrong
> Priority: Major
>
> When we enable joins for multithreaded plans, we should adjust the runtime
> filter wait time.
> A large part of the motivation for the timeout was to allow parallelism
> between the different sides of the join - there was some concern that having
> a scan block indefinitely would effectively reduce the amount of parallelism
> that the plan executed with.
> With multithreading, we want to get parallelism across multiple copies of the
> same fragment, rather than parallelism across different fragments. So this
> motivation no longer applies. Making the filter wait time unlimited would
> make query execution more predictable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
