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
|
Список | 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 по дате отправления: