Re: RFC: replace pg_stat_activity.waiting with something more descriptive

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Vladimir Borodin <root(at)simply(dot)name>, Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date: 2016-03-09 13:31:00
Message-ID: CAA4eK1+xjHkagk6C4QUkm4GSWt3khCY1zQLMPTK_WMNuVXSztw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 4, 2016 at 7:11 PM, Alexander Korotkov <aekorotkov(at)gmail(dot)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 = 492GB

Performance Data
----------------------------
min_wal_size=15GB
max_wal_size=20GB
checkpoint_timeout =15min
maintenance_work_mem = 1GB
checkpoint_completion_target = 0.9

pgbench 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.

[1] -
http://www.postgresql.org/message-id/CAA4eK1+ZeB8PMwwktf+3bRS0Pt4Ux6Rs6Aom0uip8c6shJWmyg@mail.gmail.com

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

Attachment Content-Type Size
extend_pg_stat_activity_v13.patch application/octet-stream 56.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2016-03-09 13:41:07 Re: VS 2015 support in src/tools/msvc
Previous Message Robert Haas 2016-03-09 13:30:44 Re: Proposal: RETURNING primary_key()