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 size
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 argum
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 wi
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
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
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 l
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 sh
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...
W
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
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...
W
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 p
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 approac
12 matches
Mail list logo