Affects Version/s: 1.21.0
Fix Version/s: None
Current cost#rows has a problem: it does not add well when computing cumulative cost.
So the idea is to use the number of rejected rows.
Then the field would have certain meaning:
- If the value is high, the plan is probably rejecting a lot of unrelated rows, thus it is suboptimal
- Extra Project/Calc nodes won't artificially increase rows in the cost fields. Currently each Project adds "rows" which is not very good.
- It is clear what to put to the rows field: "rejected rows" is more-or-less understandable. For Project it would be 0.
- Join/Filter/Calc nodes would show "estimated number of returned rows=X (from metadataquery), rejected rows=Y (from cost)" which would help understanding where the time is spent
That is inspired by PostgreSQL's "rows removed by filter" when running explain analyze (which is statement execution + collecting statistics on each execution plan node):