Yuan has the same idea as you. I'm also OK to change the comparison to "
Original Message:
Sent: Fri August 21, 2020 01:22 PM
From: Samuel Pizarro
Subject: Rows read versus accessed - Table performance
Hi @KAI DING
| I think the latter calculation is something like "hit ratio". The smaller the value is, the poorer the performance is,
I believe the intention was exactly that.. But hit-ratio for BPs (logical vs total_reads) makes sense.. as , normally the 2 metrics are close to each other.
But here, they won't be ! 2 rows_read to 1 rows _selected, already gives you a 50% hit-ratio. Most of the times this metric will be too low.. needing several decimal places (4 , or even 5) to be able to show up something..
------------------------------
Samuel Pizarro
Original Message:
Sent: Fri August 21, 2020 05:21 AM
From: KAI DING
Subject: Rows read versus accessed - Table performance
Hi Samuel,
Thanks for you detailed explanation!
So are you suggesting to use "ROWS READ / ROWS RETURNED" instead of "100 * (rows_selected / rows_read) %" as the factor, which indicates how many rows are read for a single selected row?
I think the latter calculation is something like "hit ratio". The smaller the value is, the poorer the performance is, though the "0.0013%" value is not very clear compared to "70K". Yuan, what's your suggestion?
------------------------------
KAI DING
Original Message:
Sent: Wed August 19, 2020 10:40 AM
From: Samuel Pizarro
Subject: Rows read versus accessed - Table performance
Hi @KAI DING , sorry for the long time to answer... (got stuck in some other urgent issues here) .
| "Currently console uses the percentage value (rows_read / rows_selected) as the percentage for this metric."
Hum, I guess you mean the opposite right.. as rows_read is always higher than rows_selected. If you use %, you should always divide by the higher (total) value. It does not makes any sense dividing rows_read by rows_selected and present that in a % format. What that % means ? nothing!
Let's put some values as example here... Look at this picture, from DSM, WLM workload summary
The "ROWS READ / ROWS RETURNED" is pretty clear! It tells me that I am reading too much rows in order to return only few of them..
In other words, the agent needs to read 70k rows in order to return a single one! Great!, interpretation is directly and precise!
What, would be the % value in this case on DMC .
If you are really doing (rows_read / rows_selected) and present that in % terms, this is wrong! this is not percentage.. (statistically speaking) , so the % sign should be removed from it.. and the metric should be presented as a regular number (it's actually a factor , how big one value is when compared with the other).
But, if DMC is doing " 100 * (rows_selected / rows_read) %" , using this 1st rows as example.. this would give us :
100 * ( 3,697,974 / 48.35 ) = 0.0013%
You would need to format the number to have 4 or even 5 decimal precision to have a significant value to show... (Most of the cases 2 decimals precision wouldn't be enough and they would all be shown as 0.00% )
Not only that.. but reading 76k , is much easier to interpret than 0.0013%.
The 1st one the interpretation is immediate.. I am reading 70k more rows that I should !
when I read 0.0013% , I have to make additional math to get how BAD I am doing the rows selection..
Regards
------------------------------
Samuel Pizarro
Original Message:
Sent: Sun August 09, 2020 10:13 PM
From: KAI DING
Subject: Rows read versus accessed - Table performance
Hi Samuel,
Currently console uses the percentage value (rows_read / rows_selected) as the percentage for this metric. Would you please let us know your thoughts about what would be more appropriate for it? thanks.
------------------------------
KAI DING
Original Message:
Sent: Tue August 04, 2020 09:44 AM
From: Samuel Pizarro
Subject: Rows read versus accessed - Table performance
Hi @KAI DING
Thanks for the update...
I still wonder what this metric will show, for those extreme cases where rows_read is extremely higher than rows_selected.
like 500.000.000 vs 100 . What this metric would show ?
not sure if % is an appropriate format for this metric. It has been a factor for a long time..
------------------------------
Samuel Pizarro
Original Message:
Sent: Tue August 04, 2020 03:43 AM
From: KAI DING
Subject: Rows read versus accessed - Table performance
Hi Samuel,
Here is the git issue to track this defect: https://github.ibm.com/tools-for-aps/zh/issues/19765
Please verify it in the next DMC release.
And thank you again for pointing out this defect!
------------------------------
KAI DING
Original Message:
Sent: Thu July 09, 2020 09:59 PM
From: KAI DING
Subject: Rows read versus accessed - Table performance
Hi Samuel,
Thanks for bringing up this issue! We'll investigate and let you know the update. thanks.
------------------------------
KAI DING
Original Message:
Sent: Wed July 08, 2020 08:15 PM
From: Samuel Pizarro
Subject: Rows read versus accessed - Table performance
Hi team
looking at table performance view, I am trying to understand what 'Rows read versus accessed/min' means.
I believe this is trying to give the famous (Rows read / Rows selected) ratio which we normally see as an factor , instead of a %.
And it seems there is some miss calculation for this column. I only get 100% or 0%, nothing in between..
------------------------------
Samuel Pizarro
------------------------------
#Db2