Re: RFC: replace pg_stat_activity.waiting with something more descriptive
| От | Amit Kapila |
|---|---|
| Тема | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
| Дата | |
| Msg-id | CAA4eK1+xjHkagk6C4QUkm4GSWt3khCY1zQLMPTK_WMNuVXSztw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Alexander Korotkov <aekorotkov@gmail.com>) |
| Ответы |
Re: RFC: replace pg_stat_activity.waiting with something
more descriptive
Re: RFC: replace pg_stat_activity.waiting with something more descriptive Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
| Список | pgsql-hackers |
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.
>
RAM = 492GB
>
>>
>> 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 threadsRAM = 492GB
Performance Data
----------------------------
min_wal_size=15GBmax_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.
Вложения
В списке pgsql-hackers по дате отправления: