Igor, 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)? Regards Neto 2017-09-08 5:46 GMT-07:00 Igor Neyman <iney...@perceptron.com>: > *From:* pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance- > ow...@postgresql.org] *On Behalf Of *Neto pr > *Sent:* Thursday, September 07, 2017 11:17 PM > *To:* pgsql-performance@postgresql.org > *Subject:* [PERFORM] 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 Neto > > Neto, > > 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 >
