6.8 M executions is very high . Worth considering hash join
On Sat, May 18, 2019 at 6:02 PM Chris Stephens <cstephens16@xxxxxxxxx>
wrote:
ah. ok. my memory fails me!Cheers,
thanks.
chris
On Sat, May 18, 2019 at 4:30 PM Andy Sayer <andysayer@xxxxxxxxx> wrote:
Actual rows is the total from all executions of that particular line.
Remember that each execution is likely to return a different number of rows.
It sounds like you have a nested loops plan that drives from a huge row
source, uses an index on filters that give about 32 rowids per loop. This
then gets filtered massively when you eventually read the table blocks.
If your table only had 680,000 rows, then the nested loop of that index
means that rows are read on average 323 times each. Sounds very inefficient.
Hope that helps,
Andy
On Sat, 18 May 2019 at 22:06, Chris Stephens <cstephens16@xxxxxxxxx>
wrote:
Is my memory getting that bad or did something change in how sql monitor--
reports actual rows and executions?
I have a plan_line_id that's an index range scan on a table with 680,000
rows reporting an "actual rows" value of 220,000,000 and an "Executions"
value of 6,861,000.
I aways though it was ("executions" x "actual rows") that got passed up
to the parent operation but that's not making sense at the moment.
Chris
