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

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 = 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