On 2/17/19 7:45 AM, Donald Dong wrote:
> On Feb 16, 2019, at 9:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Donald Dong <xdong@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