Re: RFC: replace pg_stat_activity.waiting with something more descriptive - Mailing list pgsql-hackers
| From | neha khatri |
|---|---|
| Subject | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
| Date | |
| Msg-id | CAFO0U+8=QkJexENvmNJZAxFSa1jmK+-PWJ0CXY2yhoE_p1ZTAw@mail.gmail.com Whole thread Raw |
| In response to | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Amit Kapila <amit.kapila16@gmail.com>) |
| Responses |
Re: RFC: replace pg_stat_activity.waiting with something
more descriptive
|
| List | pgsql-hackers |
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.
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? Would it be worth making that change.
Regards,
Neha
Cheers,
Neha
Neha
On Thu, Mar 10, 2016 at 12:31 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Fri, Mar 4, 2016 at 7:11 PM, Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
>>
>> If yes, then the only slight worry is that there will lot of repetition in wait_event_type column, otherwise it is okay.
>
>
> There is morerows attribute of entry tag in Docbook SGML, it behaves like rowspan in HTML.
>Thanks for the suggestion. I have updated the patch to include wait_event_type information in the wait_event table.As asked above by Robert, below is performance data with the patch.M/C Details------------------IBM POWER-8 24 cores, 192 hardware threads
RAM = 492GBPerformance Data----------------------------min_wal_size=15GB
max_wal_size=20GB
checkpoint_timeout =15min
maintenance_work_mem = 1GB
checkpoint_completion_target = 0.9pgbench read-only (median of 3, 5-min runs)
clients BASE PATCH % 1 19703.549206 19992.141542 1.4646718364 8 120105.542849 127717.835367 6.3380026745 64 487334.338764 495861.7211254 1.7498012521 The read-only data shows some improvement with patch, but I think this is mostly attributed to run-to-run variation.pgbench read-write (median of 3, 30-min runs)
clients BASE PATCH % 1 1703.275728 1696.568881 -0.3937616729 8 8884.406185 9442.387472 6.2804567394 64 32648.82798 32113.002416 -1.6411785572 In the above data, the read-write data shows small regression (1.6%) at higher client-count, but when I ran individually that test, the difference was 0.5%. I think it is mostly attributed to run-to-run variation as we see with read-only tests.Thanks to Mithun C Y for doing performance testing of this patch.As this patch is adding 4-byte variable to shared memory structure PGPROC, so this is susceptible to memory alignment issues for shared buffers as discussed in thread [1], but in general the performance data doesn't indicate any regression.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
pgsql-hackers by date: