On Fri, Mar 4, 2016 at 7:11 PM, Alexander Korotkov <aekorot...@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+3brs0pt4ux6rs6aom0uip8c6shjw...@mail.gmail.com With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
extend_pg_stat_activity_v13.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
