[docs] document LIR attribution #30899
Conversation
mgree
added
A-docs
| `winning_bids` view, while `u149` is the `wins_by_item` index. | ||
|
|
||
| The `operator` is indented using [`REPEAT`](/sql/functions/#repeat) and | ||
| `mz_lir_mapping.nesting`). The indenting, combined with ordering by |
There was a problem hiding this comment.
| `mz_lir_mapping.nesting`). The indenting, combined with ordering by | |
| `mz_lir_mapping.nesting`. The indenting, combined with ordering by |
|
|
||
| ### Attributing memory usage | ||
|
|
||
| (If you have not read about [attributing computation time](#attributing-computation-time), please do so first, as it explains some core concepts.) |
There was a problem hiding this comment.
| (If you have not read about [attributing computation time](#attributing-computation-time), please do so first, as it explains some core concepts.) | |
| {{< tip >}} | |
| If you have not read about [attributing computation time](#attributing-computation-time), please do so first, as it explains some core concepts. | |
| {{< /tip >}} |
| ```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.
| ORDER BY global_id, lir_id DESC; | ||
| ``` | ||
|
|
||
| Running this query on an auction generator will produce results that look something like the following (though the specific numbers will vary, of course): |
There was a problem hiding this comment.
Double checking - so, users would just run this query ... and it'd list everything, yes? Like we wouldn't be able to scope this to the auction generator data -- or should we also add mo.id in ('wins_by_item', 'winning_bids') ?
| [`mz_catalog.mz_objects`](/sql/system-catalog/mz_catalog/#mz_objects) | ||
| to find the actual name corresponding to the `global_id`. | ||
|
|
||
| Notice that the index is actually _two_ `global_id`s: `u148` is the |
There was a problem hiding this comment.
Should we put this sentence and the The duration column ... closer? since they have to do with things to observe from the output?
Also, should we be more explicit in what we mean by "the index is actually two global_ids: ... wins_by_item index"? That is, the create index had to execute/"materialize" the view ... or something like that because I think having the word index appear twice might confuse people.
| | wins_by_item | u149 | 8 | null | Arrange 7 | 00:00:00.013887 | 9347 | | ||
| | wins_by_item | u149 | 7 | 8 | Get::PassArrangements u148 | null | null | | ||
|
|
||
| The `duration` column lets us see that the `TopK` operator is where we |
There was a problem hiding this comment.
| The `duration` column lets us see that the `TopK` operator is where we | |
| The `duration` column shows that the `TopK` operator is where we |
| | wins_by_item | u149 | 8 | null | Arrange 7 | null | null | null | null | | ||
| | wins_by_item | u149 | 7 | 8 | Get::PassArrangements u148 | null | null | null | null | | ||
|
|
||
| Here, the hinted `DISTINCT ON INPUT GROUP SIZE` is `255.0`. We can re-create our view and index using the hint as follows: |
There was a problem hiding this comment.
| Here, the hinted `DISTINCT ON INPUT GROUP SIZE` is `255.0`. We can re-create our view and index using the hint as follows: | |
| Here, the hinted `DISTINCT ON INPUT GROUP SIZE` is `255`. We can re-create our view and index using the hint as follows: |
| 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.
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.