Re: Session WAL activity

2019-12-20 Thread Andres Freund
Hi, On 2019-12-20 16:38:32 -0500, Bruce Momjian wrote: > On Thu, Dec 12, 2019 at 09:31:22AM +0800, Craig Ringer wrote: > > On Fri, 6 Dec 2019 at 09:57, Michael Paquier wrote: > > > > On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote: > > > Concerning keeping PGPROC

Re: Session WAL activity

2019-12-20 Thread Bruce Momjian
On Thu, Dec 12, 2019 at 09:31:22AM +0800, Craig Ringer wrote: > On Fri, 6 Dec 2019 at 09:57, Michael Paquier wrote: > > On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote: > > Concerning keeping PGPROC size as small as possible, I agree that it is > > reasonable

Re: Session WAL activity

2019-12-11 Thread Craig Ringer
On Fri, 6 Dec 2019 at 09:57, Michael Paquier wrote: > On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote: > > Concerning keeping PGPROC size as small as possible, I agree that it is > > reasonable argument. > > But even now it is very large (816 bytes) and adding extra 8 bytes

Re: Session WAL activity

2019-12-11 Thread Konstantin Knizhnik
On 11.12.2019 7:26, Kyotaro Horiguchi wrote: Still I'm not sure non-atomic write is acceptable, but I agree on the necessity of updating it during a transaction. Couldn't we update shared stats every n bytes (XLOG_BLCKSZ or such) or every command end? I think we should refrain from inserting

Re: Session WAL activity

2019-12-10 Thread Kyotaro Horiguchi
At Fri, 6 Dec 2019 11:22:14 +0300, Konstantin Knizhnik wrote in > > > On 06.12.2019 4:57, Michael Paquier wrote: > > On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote: > > Please see pgstat.h, close to pgstat_report_wait_start(). > > Sorry, I do not understand what should I

Re: Session WAL activity

2019-12-06 Thread Konstantin Knizhnik
On 06.12.2019 4:57, Michael Paquier wrote: On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote: Concerning keeping PGPROC size as small as possible, I agree that it is reasonable argument. But even now it is very large (816 bytes) and adding extra 8 bytes will increase it on

Re: Session WAL activity

2019-12-05 Thread Michael Paquier
On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote: > Concerning keeping PGPROC size as small as possible, I agree that it is > reasonable argument. > But even now it is very large (816 bytes) and adding extra 8 bytes will > increase it on less than 1%. It does not mean that we

Re: Session WAL activity

2019-12-05 Thread Konstantin Knizhnik
On 05.12.2019 5:37, Kyotaro Horiguchi wrote: It seems to be useful to me. We also might want statistics of other session IOs. In that case the table name would be "pg_stat_session/process_activity". We are aleady collecting most kinds of the IO activity but it loses session information...

Re: Session WAL activity

2019-12-04 Thread Kyotaro Horiguchi
Hi. At Wed, 4 Dec 2019 16:40:27 +0300, Konstantin Knizhnik wrote in > > > On 04.12.2019 8:33, Kyotaro Horiguchi wrote: > > It seems to be useful to me. We also might want statistics of other > > session IOs. In that case the table name would be > > "pg_stat_session/process_activity". We are

Re: Session WAL activity

2019-12-04 Thread Konstantin Knizhnik
On 04.12.2019 8:33, Kyotaro Horiguchi wrote: It seems to be useful to me. We also might want statistics of other session IOs. In that case the table name would be "pg_stat_session/process_activity". We are aleady collecting most kinds of the IO activity but it loses session information...

Re: Session WAL activity

2019-12-03 Thread Kyotaro Horiguchi
204 > 4402 | checkpointer | 328 > 4404 | walwriter| 0 > (6 rows) > > > > I wonder if such extra statistic about session WAL activity is > considered to be useful? > > The only problem with this approach from my point

Session WAL activity

2019-12-03 Thread Konstantin Knizhnik
86195 4403 | background writer| 204 4402 | checkpointer | 328 4404 | walwriter| 0 (6 rows) I wonder if such extra statistic about session WAL activity is considered to be useful? The only problem with this approach