[docs] document LIR attribution #30899
Conversation
mgree
added
A-docs
| ```sql | ||
| SELECT mo.name AS name, global_id, lir_id, parent_lir_id, REPEAT(' ', nesting * 2) || operator AS operator, | ||
| SUM(duration_ns)/1000 * '1 microsecond'::INTERVAL AS duration, SUM(count) AS count | ||
| FROM mz_introspection.mz_lir_mapping mlm |
There was a problem hiding this comment.
Trivial nit (feel free to disregard). Do we want the FROM to either left-align with SELECT or right align with the 'LEFT JOIN'/'JOIN' ?
Have zero opinion as I've seen various alignments when using JOINS and I don't think we have a company style yet. But, this one seems to differ from the others.
There was a problem hiding this comment.
Fixed it so FROM aligns with the SELECT, like all the other queries I wrote. I'm happy to have these reformatted, no strong feelings.
| Running this query on an auction generator will produce results that look something like the following (though the specific numbers will vary, of course): | ||
|
|
||
|
|
||
| | name | global_id | lir_id | parent_lir_id | operator | duration | count | |
There was a problem hiding this comment.
So, markdown table like this won't preserve the spacing(I know, with all your nice indentation logic ... come on, markdown) :shakes-fist:
https://preview.materialize.com/materialize/30899/transform-data/troubleshooting/#attributing-computation-time
When I get back, I can move separate these into a data file and a table
where in the data file, can use ```mzsql annotation to maintain spacing.
There was a problem hiding this comment.
😭 Thanks!
I could also probably just force or a unicode non-breaking space in there or something, though that's a hell of a kludge. Awkward either way.
Co-authored-by: Kay Kim <[email protected]>
Co-authored-by: Kay Kim <[email protected]>
|
|
||
| You can [`EXPLAIN`](/sql/explain-plan/) a query to see how it will be | ||
| run as a dataflow. In particular, `EXPLAIN PHYSICAL PLAN` will show | ||
| the concrete, fully optimized plan that Materialize will run. (That |
There was a problem hiding this comment.
Do we typically use (...) when we're making an aside? I guess I'm curious why that wouldn't just be its own sentence.
| and other internal views to discover which parts of your query are | ||
| computationally expensive (e.g., | ||
| [`mz_introspection.mz_compute_operator_durations_histogram`](/sql/system-catalog/mz_introspection/#mz_compute_operator_durations_histogram), [`mz_introspection.mz_scheduling_elapsed`](/sql/system-catalog/mz_introspection/#mz_scheduling_elapsed)) | ||
| or consuming excessive memory (e.g., ). |
There was a problem hiding this comment.
Is this intentionally blank after the (e.g. )?
|
|
||
| ### Attributing computation time | ||
|
|
||
| One way to understand which parts of your query are 'expensive' is to |
There was a problem hiding this comment.
When you say 'expensive', I presume you mean computationally expensive thus resource/$$ expensive right?
|
|
||
| [Worker skew](/transform-data/dataflow-troubleshooting/#is-work-distributed-equally-across-workers) occurs when your data do not end up getting evenly | ||
| partitioned between workers. Worker skew can only happen when your | ||
| cluster has more than one worker. (You can query |
There was a problem hiding this comment.
Similar nit as my first comment about () instead of its own standalone sentence. 😅
Documents the LIR mapping introspection source (#29848).
Preview at https://preview.materialize.com/materialize/30899/transform-data/troubleshooting/.
Motivation
https://github.com/MaterializeInc/database-issues/issues/6551
Checklist
$T ⇔ Proto$Tmapping (possibly in a backwards-incompatible way), then it is tagged with aT-protolabel.