Re: Proposal: expose heavyweight lock wait start time in pg_stat_activity

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Alex Shapalov <shapalov(at)gmail(dot)com>
Cc: Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Proposal: expose heavyweight lock wait start time in pg_stat_activity
Date: 2026-09-24 00:50:20
Message-ID: CAGRkXqTCzm4O+YR729qH5ai9XQyE_YRTxL=OdEm05pq0nPnoHQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Alex,

> Patch attached.

Looks like the patch is missing. The archive shows no attachment.

*> So with 10,000 other locks the direct path was about 16-17x faster in>
these tests, while its cost stayed roughly constant.*

I agree the new column is faster. My question is whether that matters
in production. The frequent readers of these views are monitoring
tools, and they usually poll every X seconds or slower. At that rate 4 ms
per poll is noise, and your own pgbench run at 10 polls per second
showed no difference either. So I'm not sure the cost alone is enough
reason to add the column.

For me, creating a view is the right approach.

Thanks,
Shihao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shihao zhong 2026-09-24 00:52:23 Re: REPACK (CONCURRENTLY) loses missing values of columns added without a rewrite
Previous Message shihao zhong 2026-09-24 00:39:08 Re: Add a permission check to pg_stat_get_backend_subxact()