[
https://issues.apache.org/jira/browse/DRILL-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kunal Khatua reassigned DRILL-4909:
-----------------------------------
Assignee: Kunal Khatua
> Refinements to Drill web UI - Query profile page
> ------------------------------------------------
>
> Key: DRILL-4909
> URL: https://issues.apache.org/jira/browse/DRILL-4909
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
> Affects Versions: 1.8.0
> Reporter: Paul Rogers
> Assignee: Kunal Khatua
> Priority: Minor
>
> The plan I'm looking at has hundreds of nodes. It takes a long time to scroll
> around the pages to get to the top. Fix the tab bar at the top of the page to
> simplify navigation. "The one with Physical Plan, Visualization, etc."
> On the Physical Plan page: The top of the page displays histogram of minor
> fragment execution. However, it is hard to infer what it displays.
> * Label the x-axis. The units seem to be seconds, but a legend of: "Runtime
> (sec.)" would help.
> * Label the y-axis. Seems to be colored by major fragment, lines by minor
> fragment. But, took some sleuthing to figure this out.
> * Tooltip on each color band to identify the major fragment. (Probably too
> fiddly to label minor fragment lines.)
> * Choose a wider palette of colors. On my chart, the top two groups are
> shades of organge, the third is blue. Seems we could rotate among the
> standard set of colors for better contrast.
> In the tables:
> * For each operator, list the number of rows processed. (Available in the
> details already.)
> * In the table that sumarizes major fragments, have as a tool-tip the names
> of the minor fragments to give the numbers some meaning. That is, hovering
> over 00-xx-xx should say "Project, Merging Receiver".
> * In the table that shows minor fragments for major fragments, either add a
> list of minor fragment names to the title, or as a pop-up. That is, in the
> heading that says, "Major Fragment: 02-xx-xx", add "(PARQUET_ROW_GROUP_SCAN,
> PROJECT, ...)
> * For each minor fragment, label the host on which it runs.
> * For larger queries, shows groups by host, expanded to show fragments. (It
> is hard to read, say, 400 minor fragments in one big table. Showing 20 nodes
> (with summaries) is easier, each expanding to show 20 minor fragments.
> In the Operator Profiles overview, add a tool-tip with details about each
> operator such as:
> * Number of vector allocations
> * Number of vector extensions (increasing the size of vectors)
> * Average vector utilization (ratio of selected to unselected rows)
> * Average batch size: number of rows, bytes per row, bytes per batch
> For scanners:
> * Number of files scanned
> * Number of schemas found
> * Number of bytes read (or file length if a table scan)
> * Name of the file scanned (or first several if a group)
> For filters:
> * Rows in, rows out and selectivity (as a ratio)
> In the operator detail table:
> * Add a line for totals (records, batches)
> * Add a line for averages (most fields)
> Under the "Full JSON Profile", part of the JSON is formatted, but the plan
> part is not. Display the plan in a formatted version (with proper
> indentation). It is not very useful in the current, streamed, non-indented
> form.
> Better, move the JSON Profile to a new tab since it causes the Physical Plan
> page to get too large for large queries.
> On the Visualized Plan page,
> * The coloring of the fragments does not match the coloring used in the chart
> on the Physical Plan page. Please use the same to make them easier to
> correlate.
> * Perhaps enclose each fragment in a box (with the border passing through the
> middle of each eachange operator.
> * For each aspect of the plan, provide basic stats such as number of minor
> fragments, number of records, average time.
> * For each node, provide a link to the Physical Plan page to see more detail.
> * The visualized plan page shows the same info as the Physical Plan page.
> Better, keep each page focused and make it easy to navigate between them.
> * Naming is inconsistent between this page and the Physical Plan page.
> "HASH_AGGREGATE" on the Physical Plan page, "HashAgg" on the visualization
> page.
> On the Edit Query page, the actual field to edit the query is two lines long
> (but my query is over a dozen lines.) Then, the rest of the page repeats the
> chart, details, etc. Seems that, if I want to edit the query, I should have a
> field large enough to do so. And, I don't need the other info (I'll go to the
> corresponding tab it I want to see it.)
> Then, regarding the Query page and Edit query, can these be combined? On the
> Query page, I see the query. If the query is running, I should see a Cancel
> button. If completed, I should see an Edit button followed by a Rerun button.
> Or, better, simply provide a Cancel (if running) button and a Edit (always)
> button. Edit shifts back to the main Query tab with with the text of the
> query filled in. This behavior more clearly demonsrates that the new query is
> independent of the original one.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
