| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_stat_wal_write statistics view |
| Date: | 2017-11-07 21:46:48 |
| Message-ID: | CA+Tgmoa6DJODQwXb3CpuB=TN3hA2q63PadDYRkr0_2hOSO1-dw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 7, 2017 at 4:31 AM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> wrote:
>> Updated patch attached.
> Patch rebased.
I think the earlier concerns about the performance impact of this are
probably very valid concerns, and I don't see how the new version of
the patch gets us much closer to solving them.
I am also not sure I understand how the backend_write_blocks column is
intended to work. The only call to pgstat_send_walwrites() is in
WalWriterMain, so where do the other backends report anything?
Also, if there's only ever one global set of counters (as opposed to
one per table, say) then why use the stats collector machinery for
this at all, vs. having a structure in shared memory that can be
updated directly? It seems like adding a lot of overhead for no
functional benefit.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-11-07 21:48:16 | Re: Refactor handling of database attributes between pg_dump and pg_dumpall |
| Previous Message | Tom Lane | 2017-11-07 21:39:56 | Re: Small improvement to compactify_tuples |