Finding the Step That Actually Cost You: a Node's Own Time vs Its Children's
The actual time on a plan node includes all the time its children took, so the top of the plan always looks like the most expensive thing in it. To find the real culprit you subtract the children's time from the parent's to get the time that step spent on its own work, and remember to multiply by loops first. The answer is usually a deep, unglamorous node such as a scan or a sort, not the join at the top. This subtraction is the same trick a code profiler does with self time versus total time.
Questions this Concept answers
Why does the top node of a plan almost always look like the most expensive step in it?
J
jeremy
Text
How to calculate timings in Postgres EXPLAIN ANALYZE
This post shows how to work out how long each step of a PostgreSQL query plan actually took. The time printed on a step already includes everything underneath it, so to find what a step cost on its o…