Hi Tom,
The cost of the inner-most Nested Loop is 27 ms, but the total cost
of
the Materialize operator is 666 ms (9250 loops * 0.072 ms per
iteration). So, Materialize introduces more than 10x overhead.
Not hardly. Had the Materialize not been there, we'd have executed
the inner nestloop 9250 times, for a total cost of 9250 * 27ms.
(Actually it might have been less due to cache effects, but still
a whole lot more than 0.072 per iteration.)
I realize that Materialize saves a big amount of time in the grand
scheme, but I'm still wondering about the descrepancy between the
total cost of Materialize and the contained Nested Loop.
These numbers say that it's taking the Materialize about 120 microsec
per row returned, which seems a bit high to me considering that the
data is just sitting in a tuplestore. I surmise that you are using
a machine with slow gettimeofday() and that's causing the measurement
overhead to be high.
Do you mean, that the overhead is an artefact of timing the query? In
that case, the query should run faster than its evaluation with
EXPLAIN ANALYZE, correct?
Is there a way to test this assumption regarding the speed of
gettimeofday? I'm on a Macbook and have no idea about the performance
of its implementation.
Cheers,
Viktor
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
