On Sat, Feb 16, 2019 at 10:33 PM Donald Dong <xd...@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
