Re: Actual Cost

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Donald Dong <xdong(at)csumb(dot)edu>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Actual Cost
Date: 2019-02-17 16:29:56
Message-ID: CAMkU=1zBJNVo2DGYBgLJqpu8fyjCE_ys+msr6pOEoiwA7y5jrA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 16, 2019 at 10:33 PM Donald Dong <xdong(at)csumb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2019-02-17 16:45:47 Re: Ryu floating point output patch
Previous Message Andrew Gierth 2019-02-17 16:19:05 Re: Ryu floating point output patch