On 2020-10-15 19:49, Fujii Masao wrote:
On 2020/10/13 11:57, Masahiro Ikeda wrote:
On 2020-10-06 15:57, Masahiro Ikeda wrote:
2. Number of when new WAL file is created and zero-filled.
As Fujii-san already commented, I think it's good for tuning.
Just idea; it may be worth exposing the numbe
On 2020/10/13 11:57, Masahiro Ikeda wrote:
On 2020-10-06 15:57, Masahiro Ikeda wrote:
Hi,
I think it's better to add other WAL statistics to the pg_stat_wal view.
I'm thinking to add the following statistics. Please let me know your thoughts.
1. Basic wal statistics
* wal_records: Total n
On 2020-10-06 15:57, Masahiro Ikeda wrote:
Hi,
I think it's better to add other WAL statistics to the pg_stat_wal
view.
I'm thinking to add the following statistics. Please let me know your
thoughts.
1. Basic wal statistics
* wal_records: Total number of WAL records generated
* wal_fpi: To
Hi,
I think it's better to add other WAL statistics to the pg_stat_wal view.
I'm thinking to add the following statistics. Please let me know your
thoughts.
1. Basic wal statistics
* wal_records: Total number of WAL records generated
* wal_fpi: Total number of WAL full page images generated
On 2020-10-02 10:21, Fujii Masao wrote:
On 2020/10/01 13:35, Fujii Masao wrote:
On 2020/10/01 12:56, Masahiro Ikeda wrote:
On 2020-10-01 11:33, Amit Kapila wrote:
On Thu, Oct 1, 2020 at 6:53 AM Kyotaro Horiguchi
wrote:
At Thu, 1 Oct 2020 09:05:19 +0900, Fujii Masao
wrote in
>
>
> On 20
On 2020/10/01 13:35, Fujii Masao wrote:
On 2020/10/01 12:56, Masahiro Ikeda wrote:
On 2020-10-01 11:33, Amit Kapila wrote:
On Thu, Oct 1, 2020 at 6:53 AM Kyotaro Horiguchi
wrote:
At Thu, 1 Oct 2020 09:05:19 +0900, Fujii Masao
wrote in
>
>
> On 2020/09/30 20:21, Amit Kapila wrote:
> >
From: Fujii Masao
> I think that we can improve that, for example, by storing backend id
> into WalSndCtl and making pg_stat_get_wal_senders() directly
> get the walsender's LocalPgBackendStatus with the backend id,
> rather than joining pg_stat_get_activity() and pg_stat_get_wal_senders().
Yeah,
On 2020/10/01 10:50, tsunakawa.ta...@fujitsu.com wrote:
From: Kyotaro Horiguchi
Another reason that I mildly want to object to subdivided functions is
I was annoyed that a stats view makes many individual calls to
functions that internally share the same statistics entry. That
behavior requ
On 2020/10/01 12:56, Masahiro Ikeda wrote:
On 2020-10-01 11:33, Amit Kapila wrote:
On Thu, Oct 1, 2020 at 6:53 AM Kyotaro Horiguchi
wrote:
At Thu, 1 Oct 2020 09:05:19 +0900, Fujii Masao
wrote in
>
>
> On 2020/09/30 20:21, Amit Kapila wrote:
> > On Tue, Sep 29, 2020 at 9:23 PM Fujii Masao
On 2020-10-01 11:33, Amit Kapila wrote:
On Thu, Oct 1, 2020 at 6:53 AM Kyotaro Horiguchi
wrote:
At Thu, 1 Oct 2020 09:05:19 +0900, Fujii Masao
wrote in
>
>
> On 2020/09/30 20:21, Amit Kapila wrote:
> > On Tue, Sep 29, 2020 at 9:23 PM Fujii Masao
> > wrote:
> >>
> >> On 2020/09/29 11:51, Ma
On Thu, Oct 1, 2020 at 6:53 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 1 Oct 2020 09:05:19 +0900, Fujii Masao
> wrote in
> >
> >
> > On 2020/09/30 20:21, Amit Kapila wrote:
> > > On Tue, Sep 29, 2020 at 9:23 PM Fujii Masao
> > > wrote:
> > >>
> > >> On 2020/09/29 11:51, Masahiro Ikeda wrote:
> > >
From: Kyotaro Horiguchi
> Another reason that I mildly want to object to subdivided functions is
> I was annoyed that a stats view makes many individual calls to
> functions that internally share the same statistics entry. That
> behavior required me to provide an entry-caching feature to my
> sh
At Thu, 1 Oct 2020 09:05:19 +0900, Fujii Masao
wrote in
>
>
> On 2020/09/30 20:21, Amit Kapila wrote:
> > On Tue, Sep 29, 2020 at 9:23 PM Fujii Masao
> > wrote:
> >>
> >> On 2020/09/29 11:51, Masahiro Ikeda wrote:
> >>> On 2020-09-29 11:43, Amit Kapila wrote:
> On Tue, Sep 29, 2020 at 7:
On 2020/09/30 20:21, Amit Kapila wrote:
On Tue, Sep 29, 2020 at 9:23 PM Fujii Masao wrote:
On 2020/09/29 11:51, Masahiro Ikeda wrote:
On 2020-09-29 11:43, Amit Kapila wrote:
On Tue, Sep 29, 2020 at 7:39 AM Masahiro Ikeda wrote:
On 2020-09-28 12:43, Amit Kapila wrote:
On Mon, Sep 28, 2
On Tue, Sep 29, 2020 at 9:23 PM Fujii Masao wrote:
>
> On 2020/09/29 11:51, Masahiro Ikeda wrote:
> > On 2020-09-29 11:43, Amit Kapila wrote:
> >> On Tue, Sep 29, 2020 at 7:39 AM Masahiro Ikeda
> >> wrote:
> >>>
> >>> On 2020-09-28 12:43, Amit Kapila wrote:
> >>> > On Mon, Sep 28, 2020 at 8:24 A
On 2020/09/29 11:51, Masahiro Ikeda wrote:
On 2020-09-29 11:43, Amit Kapila wrote:
On Tue, Sep 29, 2020 at 7:39 AM Masahiro Ikeda wrote:
On 2020-09-28 12:43, Amit Kapila wrote:
> On Mon, Sep 28, 2020 at 8:24 AM Kyotaro Horiguchi
> wrote:
>>
>> At Mon, 28 Sep 2020 08:11:23 +0530, Amit Kapi
On 2020-09-29 11:43, Amit Kapila wrote:
On Tue, Sep 29, 2020 at 7:39 AM Masahiro Ikeda
wrote:
On 2020-09-28 12:43, Amit Kapila wrote:
> On Mon, Sep 28, 2020 at 8:24 AM Kyotaro Horiguchi
> wrote:
>>
>> At Mon, 28 Sep 2020 08:11:23 +0530, Amit Kapila
>> wrote in
>> > One other thing that occur
On Tue, Sep 29, 2020 at 7:39 AM Masahiro Ikeda wrote:
>
> On 2020-09-28 12:43, Amit Kapila wrote:
> > On Mon, Sep 28, 2020 at 8:24 AM Kyotaro Horiguchi
> > wrote:
> >>
> >> At Mon, 28 Sep 2020 08:11:23 +0530, Amit Kapila
> >> wrote in
> >> > One other thing that occurred to me today is can't we
On 2020-09-28 12:43, Amit Kapila wrote:
On Mon, Sep 28, 2020 at 8:24 AM Kyotaro Horiguchi
wrote:
At Mon, 28 Sep 2020 08:11:23 +0530, Amit Kapila
wrote in
> One other thing that occurred to me today is can't we keep this as
> part of PgStat_GlobalStats? We can use pg_stat_reset_shared('wal')
On Mon, Sep 28, 2020 at 8:24 AM Kyotaro Horiguchi
wrote:
>
> At Mon, 28 Sep 2020 08:11:23 +0530, Amit Kapila
> wrote in
> > One other thing that occurred to me today is can't we keep this as
> > part of PgStat_GlobalStats? We can use pg_stat_reset_shared('wal'); to
> > reset it. It seems to me t
At Mon, 28 Sep 2020 08:11:23 +0530, Amit Kapila wrote
in
> One other thing that occurred to me today is can't we keep this as
> part of PgStat_GlobalStats? We can use pg_stat_reset_shared('wal'); to
> reset it. It seems to me this is a cluster-wide stats and somewhat
> similar to some of the oth
On Mon, Sep 28, 2020 at 7:00 AM Masahiro Ikeda wrote:
>
> On 2020-09-26 19:18, Amit Kapila wrote
>
> > This makes sense to me. I think even if such background processes have
> > to write WAL due to wal_buffers, it will be accounted next time the
> > backend sends the stats.
>
> Thanks for your com
On 2020-09-26 19:18, Amit Kapila wrote:
On Fri, Sep 25, 2020 at 11:06 PM Fujii Masao
wrote:
On 2020/09/25 12:06, Masahiro Ikeda wrote:
> On 2020-09-18 11:11, Kyotaro Horiguchi wrote:
>> At Fri, 18 Sep 2020 09:40:11 +0900, Masahiro Ikeda
>> wrote in
>>> Thanks. I confirmed that it causes HOT p
At Sat, 26 Sep 2020 15:48:49 +0530, Amit Kapila wrote
in
> On Fri, Sep 25, 2020 at 11:06 PM Fujii Masao
> wrote:
> >
> > On 2020/09/25 12:06, Masahiro Ikeda wrote:
> > > On 2020-09-18 11:11, Kyotaro Horiguchi wrote:
> > >> At Fri, 18 Sep 2020 09:40:11 +0900, Masahiro Ikeda
> > >> wrote in
> >
On Fri, Sep 25, 2020 at 11:06 PM Fujii Masao
wrote:
>
> On 2020/09/25 12:06, Masahiro Ikeda wrote:
> > On 2020-09-18 11:11, Kyotaro Horiguchi wrote:
> >> At Fri, 18 Sep 2020 09:40:11 +0900, Masahiro Ikeda
> >> wrote in
> >>> Thanks. I confirmed that it causes HOT pruning or killing of
> >>> dead
On 2020/09/25 12:06, Masahiro Ikeda wrote:
On 2020-09-18 11:11, Kyotaro Horiguchi wrote:
At Fri, 18 Sep 2020 09:40:11 +0900, Masahiro Ikeda
wrote in
Thanks. I confirmed that it causes HOT pruning or killing of
dead index tuple if DecodeCommit() is called.
As you said, DecodeCommit() may ac
On 2020-09-18 11:11, Kyotaro Horiguchi wrote:
At Fri, 18 Sep 2020 09:40:11 +0900, Masahiro Ikeda
wrote in
Thanks. I confirmed that it causes HOT pruning or killing of
dead index tuple if DecodeCommit() is called.
As you said, DecodeCommit() may access the system table.
...
The wals are gener
At Fri, 18 Sep 2020 09:40:11 +0900, Masahiro Ikeda
wrote in
> Thanks. I confirmed that it causes HOT pruning or killing of
> dead index tuple if DecodeCommit() is called.
>
> As you said, DecodeCommit() may access the system table.
...
> The wals are generated only when logical replication is p
On 2020-09-15 17:10, Fujii Masao wrote:
On 2020/09/15 15:52, Masahiro Ikeda wrote:
On 2020-09-11 01:40, Fujii Masao wrote:
On 2020/09/09 13:57, Masahiro Ikeda wrote:
On 2020-09-07 16:19, Fujii Masao wrote:
On 2020/09/07 9:58, Masahiro Ikeda wrote:
Thanks for the review and advice!
On 2020-0
On 2020/09/15 15:52, Masahiro Ikeda wrote:
On 2020-09-11 01:40, Fujii Masao wrote:
On 2020/09/09 13:57, Masahiro Ikeda wrote:
On 2020-09-07 16:19, Fujii Masao wrote:
On 2020/09/07 9:58, Masahiro Ikeda wrote:
Thanks for the review and advice!
On 2020-09-03 16:05, Fujii Masao wrote:
On 202
On 2020-09-11 01:40, Fujii Masao wrote:
On 2020/09/09 13:57, Masahiro Ikeda wrote:
On 2020-09-07 16:19, Fujii Masao wrote:
On 2020/09/07 9:58, Masahiro Ikeda wrote:
Thanks for the review and advice!
On 2020-09-03 16:05, Fujii Masao wrote:
On 2020/09/02 18:56, Masahiro Ikeda wrote:
+/* -
On 2020/09/11 16:54, Kyotaro Horiguchi wrote:
At Fri, 11 Sep 2020 13:48:49 +0900, Fujii Masao
wrote in
On 2020/09/11 12:17, Kyotaro Horiguchi wrote:
Hello.
At Wed, 09 Sep 2020 13:57:37 +0900, Masahiro Ikeda
wrote in
I checked what function calls XLogBackgroundFlush() which calls
Advanc
At Fri, 11 Sep 2020 13:48:49 +0900, Fujii Masao
wrote in
>
>
> On 2020/09/11 12:17, Kyotaro Horiguchi wrote:
> > Hello.
> > At Wed, 09 Sep 2020 13:57:37 +0900, Masahiro Ikeda
> > wrote in
> >> I checked what function calls XLogBackgroundFlush() which calls
> >> AdvanceXLInsertBuffer() to incr
On 2020/09/11 12:17, Kyotaro Horiguchi wrote:
Hello.
At Wed, 09 Sep 2020 13:57:37 +0900, Masahiro Ikeda
wrote in
I checked what function calls XLogBackgroundFlush() which calls
AdvanceXLInsertBuffer() to increment m_wal_buffers_full.
I found that WalSndWaitForWal() calls it, so I added it
Hello.
At Wed, 09 Sep 2020 13:57:37 +0900, Masahiro Ikeda
wrote in
> I checked what function calls XLogBackgroundFlush() which calls
> AdvanceXLInsertBuffer() to increment m_wal_buffers_full.
>
> I found that WalSndWaitForWal() calls it, so I added it.
> Is it better to move it in WalSndLoop()
On 2020/09/09 13:57, Masahiro Ikeda wrote:
On 2020-09-07 16:19, Fujii Masao wrote:
On 2020/09/07 9:58, Masahiro Ikeda wrote:
Thanks for the review and advice!
On 2020-09-03 16:05, Fujii Masao wrote:
On 2020/09/02 18:56, Masahiro Ikeda wrote:
+/* --
+ * Backend types
+ * --
On 2020-09-07 16:19, Fujii Masao wrote:
On 2020/09/07 9:58, Masahiro Ikeda wrote:
Thanks for the review and advice!
On 2020-09-03 16:05, Fujii Masao wrote:
On 2020/09/02 18:56, Masahiro Ikeda wrote:
+/* --
+ * Backend types
+ * --
You seem to forget to add "*/" into the above
On 2020/09/07 9:58, Masahiro Ikeda wrote:
Thanks for the review and advice!
On 2020-09-03 16:05, Fujii Masao wrote:
On 2020/09/02 18:56, Masahiro Ikeda wrote:
+/* --
+ * Backend types
+ * --
You seem to forget to add "*/" into the above comment.
This issue could cause the f
Thanks for the review and advice!
On 2020-09-03 16:05, Fujii Masao wrote:
On 2020/09/02 18:56, Masahiro Ikeda wrote:
+/* --
+ * Backend types
+ * --
You seem to forget to add "*/" into the above comment.
This issue could cause the following compiler warning.
../../src/include/p
On Fri, Sep 4, 2020 at 5:42 AM Fujii Masao
wrote:
>
>
> On 2020/09/04 11:50, tsunakawa.ta...@fujitsu.com wrote:
> > From: Fujii Masao
> >>> I changed the view name from pg_stat_walwrites to pg_stat_walwriter.
> >>> I think it is better to match naming scheme with other views like
> >> pg_stat_bg
On 2020/09/04 11:50, tsunakawa.ta...@fujitsu.com wrote:
From: Fujii Masao
I changed the view name from pg_stat_walwrites to pg_stat_walwriter.
I think it is better to match naming scheme with other views like
pg_stat_bgwriter,
which is for bgwriter statistics but it has the statistics rela
From: Fujii Masao
> > I changed the view name from pg_stat_walwrites to pg_stat_walwriter.
> > I think it is better to match naming scheme with other views like
> pg_stat_bgwriter,
> > which is for bgwriter statistics but it has the statistics related to
> > backend.
>
> I prefer the view name p
On 2020/09/02 18:56, Masahiro Ikeda wrote:
+/* --
+ * Backend types
+ * --
You seem to forget to add "*/" into the above comment.
This issue could cause the following compiler warning.
../../src/include/pgstat.h:761:1: warning: '/*' within block comment [-Wcomment]
Thanks fo
+/* --
+ * Backend types
+ * --
You seem to forget to add "*/" into the above comment.
This issue could cause the following compiler warning.
../../src/include/pgstat.h:761:1: warning: '/*' within block comment
[-Wcomment]
Thanks for the comment. I fixed.
The contents of pg_s
On 2020/08/24 21:00, Masahiro Ikeda wrote:
On 2020-08-24 20:45, Masahiro Ikeda wrote:
Hi, thanks for useful comments.
I agree to expose the number of WAL write caused by full of WAL buffers.
It's helpful when tuning wal_buffers size. Haribabu separated that number
into two fields in his pat
On 2020-08-24 20:45, Masahiro Ikeda wrote:
Hi, thanks for useful comments.
I agree to expose the number of WAL write caused by full of WAL
buffers.
It's helpful when tuning wal_buffers size. Haribabu separated that
number
into two fields in his patch; one is the number of WAL write by
backend
Hi, thanks for useful comments.
I agree to expose the number of WAL write caused by full of WAL
buffers.
It's helpful when tuning wal_buffers size. Haribabu separated that
number
into two fields in his patch; one is the number of WAL write by
backend,
and another is by background processes an
On 2020/08/21 12:08, tsunakawa.ta...@fujitsu.com wrote:
From: Fujii Masao
Just idea; it may be worth exposing the number of when new WAL file is
created and zero-filled. This initialization may have impact on
the performance of write-heavy workload generating lots of WAL. If this
number is r
From: Fujii Masao
> Just idea; it may be worth exposing the number of when new WAL file is
> created and zero-filled. This initialization may have impact on
> the performance of write-heavy workload generating lots of WAL. If this
> number is reported high, to reduce the number of this initializat
From: Fujii Masao
> I agree to expose the number of WAL write caused by full of WAL buffers.
> It's helpful when tuning wal_buffers size. Haribabu separated that number
> into two fields in his patch; one is the number of WAL write by backend,
> and another is by background processes and workers.
On 2020/08/20 20:01, Fujii Masao wrote:
On 2020/08/19 14:10, Masahiro Ikeda wrote:
On 2020-08-19 13:49, tsunakawa.ta...@fujitsu.com wrote:
From: Masahiro Ikeda
If my understanding is correct, we have to measure the performance
impact first.
Do you know HariBabu is now trying to solve it?
On 2020/08/19 14:10, Masahiro Ikeda wrote:
On 2020-08-19 13:49, tsunakawa.ta...@fujitsu.com wrote:
From: Masahiro Ikeda
If my understanding is correct, we have to measure the performance
impact first.
Do you know HariBabu is now trying to solve it? If not, I will try to
modify patches to ap
On 2020-08-19 13:49, tsunakawa.ta...@fujitsu.com wrote:
From: Masahiro Ikeda
If my understanding is correct, we have to measure the performance
impact first.
Do you know HariBabu is now trying to solve it? If not, I will try to
modify patches to apply HEAD.
No, he's not doing it anymore. It'
From: Masahiro Ikeda
> If my understanding is correct, we have to measure the performance
> impact first.
> Do you know HariBabu is now trying to solve it? If not, I will try to
> modify patches to apply HEAD.
No, he's not doing it anymore. It'd be great if you could resume it. However,
I reco
On 2020-08-18 16:35, tsunakawa.ta...@fujitsu.com wrote:
From: Masahiro Ikeda
It's important to provide the metrics for tuning the size of WAL
buffers.
For now, it's lack of the statistics how often processes wait to write
WAL
because WAL buffer is full.
If those situation are often occurred,
From: Masahiro Ikeda
> It's important to provide the metrics for tuning the size of WAL buffers.
> For now, it's lack of the statistics how often processes wait to write WAL
> because WAL buffer is full.
>
> If those situation are often occurred, WAL buffer is too small for the
> workload.
> DBA
56 matches
Mail list logo
