Tim Armstrong created IMPALA-7053:
-------------------------------------
Summary: Reorganise query options into groups
Key: IMPALA-7053
URL: https://issues.apache.org/jira/browse/IMPALA-7053
Project: IMPALA
Issue Type: Improvement
Components: Backend
Reporter: Tim Armstrong
Assignee: Tim Armstrong
We have quite a lot of query options now and we're adding more for things like
resource limits (e.g. IMPALA-6035). It's getting harder for users to understand
the organisation and find relevant query options. We should consider grouping
similar query options.
E.g. for this set of resource limits, we could reorganise in various ways:
* mem_limit -> resources.memory.per_node_limit
* buffer_pool_limit -> resources.memory.buffer_pool.per_node_limit
* thread_reservation_limit -> resources.threads.per_node_limit
* thread_reservation_aggregate_limit -> resources.threads.aggregate_limit
* exec_time_limit_s -> resources.wallclock.limit_s
We could do the conversion incrementally. It would probably make sense to agree
on a top-level organisation up-front.
* planner - anything that controls planner decisions like join ordering, etc
* scheduler - anything that controls scheduler decisions (admission control
could maybe be included here too)
* resources - resource management functionality (limits, etc)
* session - anything related to session management like timeouts
* exec - anything that changes query execution behaviour (e.g. codegen, batch
sizes, runtime filters, etc)
* Probably a group for anything that changes the semantic behaviour of a query
(e.g. decimal_v2, appx_count_distinct, strict_mode, abort_on_error).
* A group that controls read and write behaviour of file formats like
compression, etc
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
