On 2/17/19 7:45 AM, Donald Dong wrote: > On Feb 16, 2019, at 9:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> Donald Dong <xd...@csumb.edu> writes: >>> On Feb 16, 2019, at 6:44 PM, Tomas Vondra wrote: >>>> 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'm with Tomas: you have not explained what you think those >> numbers mean. > > Yeah, I was considering the actual cost to be the output of the cost > model given the actual rows and pages after we instrument the > execution: plug in the values which are no longer estimations. > > For a hash join, we could use the actual inner_rows_total to get the > actual cost. For a seqscan, we can use the actual rows to get the > actual CPU cost. >
Perhaps I'm just too used to comparing the rows/pages directly, but I don't quite see the benefit of having such "actual cost". Mostly because the cost model is rather rough anyway. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
