You're right, I confused the radix character.
But even so the result is approximate to the previous message, 182 minutes, see below:
419.113 / 1000 = 0.41 seconds * 26469 (loops) = 11093.50 seconds or 184 minutes
After analyzing, I saw that in some places of the plan, it is being used Parallelism. Does this explain why the final value spent (in minutes) to go through the index (184 minutes) is greater than the total query time (66 minutes)?
Neto
From: pgsql-performance-owner@
postgresql.org [mailto:pgsql-performance-owner@xxxxxxxxxxxxxx ] On Behalf Of Neto pr
Sent: Thursday, September 07, 2017 11:17 PM
To: pgsql-performance@postgresql.org
Subject: Explain Analyze - actual time in loops
…
##############################
## ############################## ……………….#####
-> Index Scan using idx_l_partkeylineitem000x on lineitem (cost = 0.57..97.65 rows = 26 width = 36)
(current time = 23.615..419.113 rows = 30 loops = 26469)
Index Cond: (l_partkey = part.p_partkey)
################################################## #################
According to the documentation, one should multiply the Actual Time by the number of Loops.
That is: 419113 ms -> 419113/1000/60 = 6.9 minutes * 26469 (loops) = 182.6 minutes.
But how does this stretch take 182.6 minutes, if the entire query ran in 66 minutes?
thank you and best regards
[] 's NetoNeto,
The time you see there is in ms, so the point (‘.’) you see is the digital point.
So, it is 419.113ms or a little less than half a second (0.419sec).
Igor Neyman
