Re: Proposal: expose heavyweight lock wait start time in pg_stat_activity - Mailing list pgsql-hackers

From shihao zhong
Subject Re: Proposal: expose heavyweight lock wait start time in pg_stat_activity
Date
Msg-id CAGRkXqTCzm4O+YR729qH5ai9XQyE_YRTxL=OdEm05pq0nPnoHQ@mail.gmail.com
Whole thread
In response to Re: Proposal: expose heavyweight lock wait start time in pg_stat_activity  (Alex Shapalov <shapalov@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: shihao zhong
Date:
Subject: Re: Add a permission check to pg_stat_get_backend_subxact()
Next
From: shihao zhong
Date:
Subject: Re: REPACK (CONCURRENTLY) loses missing values of columns added without a rewrite