Re: Some belated patch review for "Buffers" explain analyze patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Some belated patch review for "Buffers" explain analyze patch
Date
Msg-id 1487.1265761934@sss.pgh.pa.us
Whole thread Raw
In response to Re: Some belated patch review for "Buffers" explain analyze patch  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Some belated patch review for "Buffers" explain analyze patch
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Feb 9, 2010 at 6:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Not in the least. �Fixing EXPLAIN to consistently print totals would
>> involve changes in (at least) the treatment of estimated costs, and very
>> possibly some changes in the Instrumentation support as well.

> As far as I am aware there is one place (in ExplainNode) where all the
> division happens for the regular estimates, and one place in that same
> function that would need to be changed for EXPLAIN BUFFERS.

The above statement proves that you don't understand the problem ...

The reason that EXPLAIN prints things the way it does is so that actual
costs/times are comparable to estimated costs.  Because estimated costs
are built bottom-up, the cost of a lower plan node is not dependent on
the number of times it's iterated as a result of an upper node deciding
to rescan it.  If we change things so that the displayed actual costs
are totals rather than per-iteration, we'd have to do something to fix
the displayed estimates.

Now that might not be enormously difficult, but it's not trivial,
and it's certainly a larger change than just deciding to change
(or not) the recently-added hash statistics printout.

But the larger picture is that I agree with Greg's feeling that choosing
to completely change the way that EXPLAIN's outputs are defined is not
something to be done at the tail end of a devel cycle.  Maybe it'll be
better but I'd like to have some time with it under our belts before
we're committed.

And, btw, if you think this isn't documented then you haven't read the
relevant documentation.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Listen / Notify - what to do when the queue is full
Next
From: KaiGai Kohei
Date:
Subject: Re: Largeobject Access Controls (r2460)