- 17.9K All Categories
- 3.4K Industry Applications
- 3.3K Intelligent Advisor
- 62 Insurance
- 536K On-Premises Infrastructure
- 138.2K Analytics Software
- 38.6K Application Development Software
- 5.7K Cloud Platform
- 109.4K Database Software
- 17.5K Enterprise Manager
- 8.8K Hardware
- 71.1K Infrastructure Software
- 105.2K Integration
- 41.5K Security Software
A second A-Row column for input rows in the traces
I think the idea has been mentioned many years ago - maybe by Jonathan Lewis in Cost Based Oracle Fundamentals, or by someone else somewhere else...
The A-Rows information displayed by different trace utilities (rowsource statistics in dbms_xplan.display_cursor and sqlmonitor) shows the number of output rows returned by a step in the execution plan: but there are situations in which it would be also of interest to know the number of input rows for a given step. A fitting example is Explain plan control - hash join running long: a hash join returns just a few rows (shown by sqlmonitor as A-Rows), but the intermediate result contains billions of rows that are excluded by a filter.
So it would be a helpful to gather this information with the rowsource instrumentation code (if this is not already done) and display it in the corresponding plans.
16.04.2015: Randolf Geist provided are more complete explanantion of the problem (and possible solutions) in his blog: Oracle related stuff: Combined ACCESS And FILTER Predicates - Excessive Throw-Away. And I also think that AE-rows (Actually Evaluated Rows) would be a good name.