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

Поиск
Список
Период
Сортировка
От Thom Brown
Тема Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Дата
Msg-id CAA-aLv4pXa56aNiXf=UUv5JL2mEAR-nfw6XESoCv6GFYpXAKgQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On 9 March 2016 at 13:31, Amit Kapila <amit.kapila16@gmail.com> wrote:
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.



The new patch looks fine with regards to grammar and spelling.

However, the new row-spanning layout isn't declared correctly as you've over-counted by 1 in each morerows attribute, possibly because you equated it to the rowspan attribute in html, which will add one above whatever you specify in the document.  "morerows" isn't the total number or rows, but how many more rows in addition to the current one will the row span.

And yes, as Robert mentioned, please can we remove the "A server process is" repetition?
 
Thom

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Declarative partitioning
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: WAL log only necessary part of 2PC GID