Re: [HACKERS] pg_stat_wal_write statistics view

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: [HACKERS] pg_stat_wal_write statistics view
Дата
Msg-id CAJrrPGfP5xdvLCEvCZOPMLzO-PGTqWNfavW1FV3TL-fDpWwOpA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_stat_wal_write statistics view  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: [HACKERS] pg_stat_wal_write statistics view  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Список pgsql-hackers


On Fri, Sep 22, 2017 at 5:46 PM, Julien Rouhaud <rjuju123@gmail.com> wrote:
Hello,

On Wed, Sep 13, 2017 at 3:01 AM, Haribabu Kommi
<kommi.haribabu@gmail.com> wrote:
> I ran the latest performance tests with and without IO times, there is an
> overhead involved with IO time calculation and didn't observe any
> performance
> overhead with normal stats. May be we can enable the IO stats only in the
> development environment to find out the IO stats?
>

-1 for me to have these columns depending on a GUC *and* wether it's a
debug or assert build (unless this behaviour already exists for other
functions, but AFAIK that's not the case).

> I added the other background stats to find out how much WAL write is
> carried out by the other background processes. Now I am able to collect
> the stats for the other background processes also after the pgbench test.
> So I feel now the separate background stats may be useful.
>
> Attached latest patch, performance test results and stats details with
> separate background stats and also combine them with backend including
> the IO stats also.
>

The results seem to vary too much to have a strong opinion, but it
looks like the timing instrumentation can be too expensive, so I'd be
-1 on adding this overhead to track_io_timing.

Thanks for the review.
I removed the time related columns from the view. As these columns are adding
an overhead and GUC controlled behavior is different to the other views.

Apart from above time columns, I removed walwriter_dirty_writes, as the
walwriter writers cannot be treated as dirty writes. 

I have some minor comments on the last patch:

+    <row>
+      <entry><structfield>backend_writes</></entry>
+      <entry><type>bigint</type></entry>
+      <entry>Number of WAL writes that are carried out by the backend
process</entry>

it should be backend processes

Changed.
 
+#define NUM_PG_STAT_WALWRITE_ATTS 16
+
+Datum
+pg_stat_get_walwrites(PG_FUNCTION_ARGS)
+{
+   TupleDesc   tupdesc;
+   Datum       values[NUM_PG_STAT_WALWRITE_ATTS];
+   bool        nulls[NUM_PG_STAT_WALWRITE_ATTS];

For consistency, the #define should be just before the tupdesc
declaration, and be named PG_STAT_GET_WALWRITE_COLS
 
Changed.


+   PgStat_Counter backend_writes;      /* No of writes by backend */

+   PgStat_Counter backend_dirty_writes;        /* No of dirty writes by
+                                                * backend when WAL buffers
+                                                * full */

+   PgStat_Counter backend_write_blocks;    /* Total no of pages
written by backend */

these comments should all be say "backends" for consistency

Changed.
 
+-- There will surely and maximum one record
+select count(*) > 0 as ok from pg_stat_walwrites;

The test should be count(*) = 1

Changed.

Updated patch attached.

Regards,
Hari Babu
Fujitsu Australia
Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] A design for amcheck heapam verification
Следующее
От: Albe Laurenz
Дата:
Сообщение: Re: [HACKERS] Enhancements to passwordcheck