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  (Robert Haas <robertmhaas@gmail.com>)
Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Thom Brown <thom@linux.com>)
Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (neha khatri <nehakhatri5@gmail.com>)
Список 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.
>

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)

clientsBASEPATCH%
119703.54920619992.1415421.4646718364
8120105.542849127717.8353676.3380026745
64487334.338764495861.72112541.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)

clientsBASEPATCH%
11703.2757281696.568881-0.3937616729
88884.4061859442.3874726.2804567394
6432648.8279832113.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.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Proposal: RETURNING primary_key()
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: VS 2015 support in src/tools/msvc