[
https://issues.apache.org/jira/browse/IMPALA-13186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871812#comment-17871812
]
Michael Smith commented on IMPALA-13186:
----------------------------------------
One open question: does it matter if we compute the query options hash in the
backend or frontend? Query option tags are defined in the backend, but all
query options are known during planning in the frontend.
So it probably makes sense to load the list in the frontend at startup (or
compile it in, which would mean keeping the list separate from where we declare
QUERY_OPT_FN), then add it to TupleCacheInfo. But in practice I'm not sure it
matters and it would be somewhat simpler to add it to the cache key in the
backend.
> Tuple cache keys should incorporate information about related query options
> ---------------------------------------------------------------------------
>
> Key: IMPALA-13186
> URL: https://issues.apache.org/jira/browse/IMPALA-13186
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
> Affects Versions: Impala 4.5.0
> Reporter: Joe McDonnell
> Assignee: Michael Smith
> Priority: Major
>
> Currently, the tuple cache key does not include information from the query
> options. Many query options have no impact on the result of a query (e.g.
> idle_session_timeout) or are evaluated purely on the coordinator during
> planning (e.g. broadcast_bytes_limit).
> However, some query options can impact behavior either by controlling how
> certain things are calculated (e.g. decimal_v2) or controlling what
> conditions result in an error. Changing a query option can change the output
> of a query.
> We need some way to incorporate the relevant query options into the tuple
> cache key so there is no correctness issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
