Re: Track the amount of time waiting due to cost_delay - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Track the amount of time waiting due to cost_delay
Date
Msg-id Z1sMFoHgavdrYJnC@nathan
Whole thread Raw
In response to Re: Track the amount of time waiting due to cost_delay  (Masahiro Ikeda <ikedamsh@oss.nttdata.com>)
List pgsql-hackers
On Thu, Dec 12, 2024 at 04:36:21AM +0000, Bertrand Drouvot wrote:
> --- a/src/backend/catalog/system_views.sql
> +++ b/src/backend/catalog/system_views.sql
> @@ -1222,7 +1222,8 @@ CREATE VIEW pg_stat_progress_vacuum AS
>          S.param4 AS heap_blks_vacuumed, S.param5 AS index_vacuum_count,
>          S.param6 AS max_dead_tuple_bytes, S.param7 AS dead_tuple_bytes,
>          S.param8 AS num_dead_item_ids, S.param9 AS indexes_total,
> -        S.param10 AS indexes_processed
> +        S.param10 AS indexes_processed,
> +        make_interval(secs => S.param11 / 1000) AS total_delay
>      FROM pg_stat_get_progress_info('VACUUM') AS S
>          LEFT JOIN pg_database D ON S.datid = D.oid;

I think we need to cast one of the operands to "double precision" to avoid
chopping off the fractional part of the result of the division, which seems
important for this case since we are dealing with lots of small sleeps.

Otherwise, at a glance, I think this one is just about ready for commit.

-- 
nathan



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Fix early elog(FATAL)
Next
From: "David G. Johnston"
Date:
Subject: Re: Document NULL