Re: RFC: replace pg_stat_activity.waiting with something more descriptive - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date
Msg-id CAA4eK1+AyjM6vj4TAFPrQpss9LzwPakUjnXEQq6wArsRsdJkqw@mail.gmail.com
Whole thread Raw
In response to Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (neha khatri <nehakhatri5@gmail.com>)
List pgsql-hackers
On Fri, Aug 26, 2016 at 4:59 AM, neha khatri <nehakhatri5@gmail.com> wrote:
Hello,

I noticed that a small optimization is possible in the flow of wait stat reporting for the LWLocks, when the pgstat_track_activities is disabled. 
If the check for pgstat_track_activities is done before invoking  LWLockReportWaitStart() instead of inside the pgstat_report_wait_start(), it can save some of the statements execution where the end result of LWLockReportWaitStart() is a NO-OP because pgstat_track_activities = false.


This is only called in slow path which means when we have to wait or sleep, so saving few instructions will not make much difference.  Note that both the functions you have mentioned are inline functions.   However, If you want, you can try that way and see if this leads to any gain.
 
I also see, that there are other callers of pgstat_report_wait_start() as well, which would also have to change to add a check for the pg_stat_activities, if the check is removed from the pgstat_report_wait_start(). Is the pg_stat_activities check inside pgstat_report_wait_start() because of some protocol being followed?

Not as such, but that variable is mainly used in pgstat.c/.h only.
 
Would it be worth making that change.


-1 for the proposed change.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Venkata B Nagothi
Date:
Subject: Re: patch proposal
Next
From: Stephen Frost
Date:
Subject: Re: patch proposal