Re: Actual Cost - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Actual Cost
Date
Msg-id 5fad6ff1-7f6e-d600-6f47-3347cc63d40c@2ndquadrant.com
Whole thread Raw
In response to Re: Actual Cost  (Donald Dong <xdong@csumb.edu>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter)
Next
From: Fabien COELHO
Date:
Subject: Re: libpq host/hostaddr/conninfo inconsistencies