Re: Actual Cost - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Actual Cost
Date
Msg-id CAMkU=1zBJNVo2DGYBgLJqpu8fyjCE_ys+msr6pOEoiwA7y5jrA@mail.gmail.com
Whole thread Raw
In response to Re: Actual Cost  (Donald Dong <xdong@csumb.edu>)
Responses Re: Actual Cost  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Actual Cost  (Donald Dong <xdong@csumb.edu>)
Re: Actual Cost  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Sat, Feb 16, 2019 at 10:33 PM Donald Dong <xdong@csumb.edu> wrote:
On Feb 16, 2019, at 6:44 PM, Tomas Vondra wrote:
>
> On 2/17/19 3:40 AM, David Fetter wrote:
>>
>> As someone not volunteering to do any of the work, I think it'd be a
>> nice thing to have.  How large an effort would you guess it would be
>> to build a proof of concept?
>
> I don't quite understand what is meant by "actual cost metric" and/or
> how is that different from running EXPLAIN ANALYZE.

Here is an example:

Hash Join  (cost=3.92..18545.70 rows=34 width=32) (actual cost=3.92..18500 time=209.820..1168.831 rows=47 loops=3)

Now we have the actual time. Time can have a high variance (a change
in system load, or just noises), but I think the actual cost would be
less likely to change due to external factors.

I don't think there is any way to assign an actual cost.  For example how do you know if a buffer read was "actually" seq_page_cost or random_page_cost?  And if there were a way, it too would have a high variance.

What would I find very useful is a verbosity option to get the cost estimates expressed as a multiplier of each *_cost parameter, rather than just as a scalar.  And at the whole-query level, get an rusage report rather than just wall-clock duration.  And if the HashAggregate node under "explain analyze" would report memory and bucket stats; and if the Aggregate node would report...anything.

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Ryu floating point output patch
Next
From: Andrew Dunstan
Date:
Subject: Re: Ryu floating point output patch