Re: another query optimization question
От | Tom Lane |
---|---|
Тема | Re: another query optimization question |
Дата | |
Msg-id | 17545.1075490366@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: another query optimization question (David Teran <david.teran@cluster9.com>) |
Ответы |
Re: another query optimization question
Re: another query optimization question |
Список | pgsql-performance |
David Teran <david.teran@cluster9.com> writes: > [ query plan ] I got a little distracted by the bizarre actual-time values shown for some of the query steps: > -> Merge Join (cost=2451266.53..2655338.83 rows=13604393 width=8) > (actual time=82899.466..-2371037.726 rows=2091599 loops=1) > -> Sort (cost=2451169.10..2483246.47 rows=12830947 width=8) > (actual time=82891.076..-529619.213 rows=4187378 loops=1) > -> Hash IN Join (cost=507.32..439065.37 rows=12830947 > width=8) (actual time=61.943..1874640.807 rows=4187378 loops=1) The hash-join total time is obviously wrong seeing that the total runtime is only about 100000 msec, and the negative values for the other two are even more obviously wrong. I recall that we saw similar symptoms once before, and I thought we'd fixed it, but I didn't find any relevant mentions in the CVS logs. What version are you running, exactly? Could you repeat the EXPLAIN with client_min_messages set to 'debug2', and see if you see any messages about InstrStartTimer or InstrStopNode? regards, tom lane
В списке pgsql-performance по дате отправления: