Robert Haas writes:
> I'm confused by why SLRU statistics are reported by messages sent to
> the stats collector rather than by just directly updating shared
> memory.
It would be better to consider that as an aspect of the WIP stats
collector redesign, rather than inventing a bes
On Thu, May 14, 2020 at 2:27 AM Fujii Masao wrote:
> Therefore what we can do right now seems to make checkpointer report the SLRU
> stats while it's running. Other issues need more time to investigate...
> Thought?
I'm confused by why SLRU statistics are reported by message
On 2020/05/07 13:47, Fujii Masao wrote:
On 2020/05/03 1:59, Tomas Vondra wrote:
On Sat, May 02, 2020 at 12:55:00PM +0200, Tomas Vondra wrote:
On Sat, May 02, 2020 at 03:56:07PM +0900, Fujii Masao wrote:
...
Another thing I found is; pgstat_send_slru() should be called also by
other pr
Fujii Masao writes:
> On 2020/05/14 2:44, Tom Lane wrote:
>> I got through check-world with the assertion shown that we are not
>> counting any SLRU operations in the postmaster. Don't know if we
>> want to commit that or not --- any thoughts?
> +1 to add this assertion because basically it's no
On 2020/05/14 2:44, Tom Lane wrote:
I wrote:
(IIRC only the Async module is doing that.)
Hm, maybe we can fix that.
Yeah, it's quite easy to make async.c postpone its first write to the
async SLRU. This seems like a win all around, because many installations
don't use NOTIFY and so will
> > Why is that necessary? A static variable is defined by C to start off
> > as zeroes.
>
> Because SLRUStats is not a static variable. No?
>
IMHO, BgWriterStats have the same problem, shouldn't the same be done?
/* Initialize BgWriterStats to zero */
MemSet(&B
I wrote:
>>> (IIRC only the Async module is doing that.)
> Hm, maybe we can fix that.
Yeah, it's quite easy to make async.c postpone its first write to the
async SLRU. This seems like a win all around, because many installations
don't use NOTIFY and so will never need to do that work at all. In
Fujii Masao writes:
> But since the counter that postmaster incremented is propagated to
> child processes via fork, it should be zeroed at postmaster or the
> beginning of child process? Otherwise that counter always starts
> with non-zero in child process.
Yes, if the postmaster is incrementing
On 2020/05/14 1:14, Alvaro Herrera wrote:
On 2020-May-14, Fujii Masao wrote:
So I tried the similar test again and found that postmaster seems to be
able to increment the counters unless I'm missing something.
For example,
frame #2: 0x00010d93845f
postgres`pgstat_count_slru_page_z
On 2020-May-14, Fujii Masao wrote:
> So I tried the similar test again and found that postmaster seems to be
> able to increment the counters unless I'm missing something.
> For example,
>
> frame #2: 0x00010d93845f
> postgres`pgstat_count_slru_page_zeroed(ctl=0x00010de27320) at
> p
On 2020/05/14 0:38, Tom Lane wrote:
Tomas Vondra writes:
I think it counts as a variable with "static storage duration" per 6.7.8
(para 10), see [1]. I wasn't aware of this either, but it probably means
the memset is unnecessary.
Also, it seems a bit strange/confusing to handle this differen
Tomas Vondra writes:
> I think it counts as a variable with "static storage duration" per 6.7.8
> (para 10), see [1]. I wasn't aware of this either, but it probably means
> the memset is unnecessary.
> Also, it seems a bit strange/confusing to handle this differently from
> BgWriterStats. And that
On Wed, May 13, 2020 at 11:46:30PM +0900, Fujii Masao wrote:
On 2020/05/13 23:26, Tom Lane wrote:
Fujii Masao writes:
On 2020/05/13 17:21, Tomas Vondra wrote:
On Wed, May 13, 2020 at 04:10:30PM +0900, Fujii Masao wrote:
Also I found another minor issue; SLRUStats has not been initialized t
On Wed, May 13, 2020 at 11:01:47AM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Wed, May 13, 2020 at 10:26:39AM -0400, Tom Lane wrote:
Why is that necessary? A static variable is defined by C to start off
as zeroes.
But is it a static variable? It's not declared as 'static' but maybe we
Tomas Vondra writes:
> On Wed, May 13, 2020 at 10:26:39AM -0400, Tom Lane wrote:
>> Why is that necessary? A static variable is defined by C to start off
>> as zeroes.
> But is it a static variable? It's not declared as 'static' but maybe we
> can assume it inits to zeroes anyway? I see we do th
On Wed, May 13, 2020 at 10:26:39AM -0400, Tom Lane wrote:
Fujii Masao writes:
On 2020/05/13 17:21, Tomas Vondra wrote:
On Wed, May 13, 2020 at 04:10:30PM +0900, Fujii Masao wrote:
Also I found another minor issue; SLRUStats has not been initialized to 0
and which could update the counters une
On 2020/05/13 23:26, Tom Lane wrote:
Fujii Masao writes:
On 2020/05/13 17:21, Tomas Vondra wrote:
On Wed, May 13, 2020 at 04:10:30PM +0900, Fujii Masao wrote:
Also I found another minor issue; SLRUStats has not been initialized to 0
and which could update the counters unexpectedly. Attache
Fujii Masao writes:
> On 2020/05/13 17:21, Tomas Vondra wrote:
>> On Wed, May 13, 2020 at 04:10:30PM +0900, Fujii Masao wrote:
>>> Also I found another minor issue; SLRUStats has not been initialized to 0
>>> and which could update the counters unexpectedly. Attached patch fixes
>>> this issue.
>
On 2020/05/13 17:21, Tomas Vondra wrote:
On Wed, May 13, 2020 at 04:10:30PM +0900, Fujii Masao wrote:
On 2020/05/07 13:47, Fujii Masao wrote:
On 2020/05/03 1:59, Tomas Vondra wrote:
On Sat, May 02, 2020 at 12:55:00PM +0200, Tomas Vondra wrote:
On Sat, May 02, 2020 at 03:56:07PM +0900,
On Wed, May 13, 2020 at 04:10:30PM +0900, Fujii Masao wrote:
On 2020/05/07 13:47, Fujii Masao wrote:
On 2020/05/03 1:59, Tomas Vondra wrote:
On Sat, May 02, 2020 at 12:55:00PM +0200, Tomas Vondra wrote:
On Sat, May 02, 2020 at 03:56:07PM +0900, Fujii Masao wrote:
...
Another thing I f
On 2020/05/07 13:47, Fujii Masao wrote:
On 2020/05/03 1:59, Tomas Vondra wrote:
On Sat, May 02, 2020 at 12:55:00PM +0200, Tomas Vondra wrote:
On Sat, May 02, 2020 at 03:56:07PM +0900, Fujii Masao wrote:
...
Another thing I found is; pgstat_send_slru() should be called also by
other pro
tmaster/pgstat.c
+++ b/src/backend/postmaster/pgstat.c
@@ -2900,6 +2900,9 @@ pgstat_initialize(void)
MyBEEntry = &BackendStatusArray[MaxBackends + MyAuxProcType];
}
+ /* Initialize SLRU statistics to zero */
+ memset(&SLRUStats, 0, sizeof(SLRUStats))
On Sat, May 02, 2020 at 12:55:00PM +0200, Tomas Vondra wrote:
On Sat, May 02, 2020 at 03:56:07PM +0900, Fujii Masao wrote:
...
Another thing I found is; pgstat_send_slru() should be called also by
other processes than backend? For example, since clog data is flushed
basically by checkpointer
On Sat, May 02, 2020 at 03:56:07PM +0900, Fujii Masao wrote:
On 2020/05/02 9:08, Tomas Vondra wrote:
On Fri, May 01, 2020 at 11:49:51AM +0900, Fujii Masao wrote:
On 2020/05/01 3:19, Tomas Vondra wrote:
On Fri, May 01, 2020 at 03:02:59AM +0900, Fujii Masao wrote:
On 2020/04/02 9:41, Toma
On 2020/05/02 9:08, Tomas Vondra wrote:
On Fri, May 01, 2020 at 11:49:51AM +0900, Fujii Masao wrote:
On 2020/05/01 3:19, Tomas Vondra wrote:
On Fri, May 01, 2020 at 03:02:59AM +0900, Fujii Masao wrote:
On 2020/04/02 9:41, Tomas Vondra wrote:
Hi,
I've pushed this after some minor clean
On Fri, May 01, 2020 at 11:49:51AM +0900, Fujii Masao wrote:
On 2020/05/01 3:19, Tomas Vondra wrote:
On Fri, May 01, 2020 at 03:02:59AM +0900, Fujii Masao wrote:
On 2020/04/02 9:41, Tomas Vondra wrote:
Hi,
I've pushed this after some minor cleanup and improvements.
+static char *slru_na
On 2020/05/01 3:19, Tomas Vondra wrote:
On Fri, May 01, 2020 at 03:02:59AM +0900, Fujii Masao wrote:
On 2020/04/02 9:41, Tomas Vondra wrote:
Hi,
I've pushed this after some minor cleanup and improvements.
+static char *slru_names[] = {"async", "clog", "commit_timestamp",
+
On Fri, May 01, 2020 at 03:02:59AM +0900, Fujii Masao wrote:
On 2020/04/02 9:41, Tomas Vondra wrote:
Hi,
I've pushed this after some minor cleanup and improvements.
+static char *slru_names[] = {"async", "clog", "commit_timestamp",
+ "
On 2020/04/02 9:41, Tomas Vondra wrote:
Hi,
I've pushed this after some minor cleanup and improvements.
+static char *slru_names[] = {"async", "clog", "commit_timestamp",
+ "multixact_offset",
"multixact_member",
+
On Tue, Apr 07, 2020 at 05:01:37PM +0530, Kuntal Ghosh wrote:
Hello Tomas,
On Thu, Apr 2, 2020 at 5:59 PM Tomas Vondra
wrote:
Thank you for the patch, pushed.
In SimpleLruReadPage_ReadOnly, we first try to find the SLRU page in
shared buffer under shared lock, then conditionally visit
Simple
Hello Tomas,
On Thu, Apr 2, 2020 at 5:59 PM Tomas Vondra
wrote:
> Thank you for the patch, pushed.
>
In SimpleLruReadPage_ReadOnly, we first try to find the SLRU page in
shared buffer under shared lock, then conditionally visit
SimpleLruReadPage if reading is necessary. IMHO, we should update
hit
On Thu, Apr 02, 2020 at 02:04:10AM +, Shinoda, Noriyoshi (PN Japan A&PS
Delivery) wrote:
Hi,
Thank you for developing great features.
The attached patch is a small fix to the committed documentation for the data
type name of blks_hit column.
Thank you for the patch, pushed.
regards
-
, 2020 9:42 AM
To: Alvaro Herrera
Cc: Masahiko Sawada ;
tsunakawa.ta...@fujitsu.com; pgsql-hack...@postgresql.org
Subject: Re: SLRU statistics
Hi,
I've pushed this after some minor cleanup and improvements.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
Postg
Hi,
I've pushed this after some minor cleanup and improvements.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
end/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c
index 4763c24be9..ea0fdade58 100644
--- a/src/backend/postmaster/pgstat.c
+++ b/src/backend/postmaster/pgstat.c
@@ -141,6 +141,24 @@ char *pgstat_stat_tmpname = NULL;
*/
PgStat_MsgBgWriter BgWriterStats;
+/*
+ * SLRU statistics
.c
+++ b/src/backend/postmaster/pgstat.c
@@ -141,6 +141,25 @@ char *pgstat_stat_tmpname = NULL;
*/
PgStat_MsgBgWriter BgWriterStats;
+/*
+ * SLRU statistics counters (unused in other processes) stored directly in
+ * stats structure so it can be sent without needing to copy things around.
+ * We assume
gStat_MsgSlru *msg, int len);
static void pgstat_recv_funcstat(PgStat_MsgFuncstat *msg, int len);
static void pgstat_recv_funcpurge(PgStat_MsgFuncpurge *msg, int len);
static void pgstat_recv_recoveryconflict(PgStat_MsgRecoveryConflict *msg, int
len);
@@ -907,6 +913,9 @@ pgstat_report_stat(bool f
On 2020-Feb-29, Tomas Vondra wrote:
> Did we actually remove track-enabling GUCs? I think we still have
>
> - track_activities
> - track_counts
> - track_io_timing
> - track_functions
>
> But maybe I'm missing something?
Hm I remembered we removed the one for row-level stats
(track_row_stat
On Fri, Feb 28, 2020 at 08:19:18PM -0300, Alvaro Herrera wrote:
On 2020-Jan-21, Tomas Vondra wrote:
On Tue, Jan 21, 2020 at 05:09:33PM +0900, Masahiko Sawada wrote:
> I've not tested the performance impact but perhaps we might want to
> disable these counter by default and controlled by a GU
On 2020-Jan-21, Tomas Vondra wrote:
> On Tue, Jan 21, 2020 at 05:09:33PM +0900, Masahiko Sawada wrote:
> > I've not tested the performance impact but perhaps we might want to
> > disable these counter by default and controlled by a GUC. And similar
> > to buffer statistics it might be better to i
On Tue, Jan 21, 2020 at 06:24:29AM +, tsunakawa.ta...@fujitsu.com
wrote:
From: Tomas Vondra
You're right the users can't really take advantage of this - my
primary motivation was providing a feedback for devs, benchmarking
etc. That might have been done with DEBUG messages or something, but
On Tue, Jan 21, 2020 at 05:09:33PM +0900, Masahiko Sawada wrote:
On Tue, 21 Jan 2020 at 01:38, Tomas Vondra wrote:
On Mon, Jan 20, 2020 at 01:04:33AM +, tsunakawa.ta...@fujitsu.com wrote:
>From: Tomas Vondra
>> One of the stats I occasionally wanted to know are stats for the SLRU
>> stats
On Tue, 21 Jan 2020 at 01:38, Tomas Vondra wrote:
>
> On Mon, Jan 20, 2020 at 01:04:33AM +, tsunakawa.ta...@fujitsu.com wrote:
> >From: Tomas Vondra
> >> One of the stats I occasionally wanted to know are stats for the SLRU
> >> stats (we have couple of those - clog, subtrans, ...). So here i
From: Tomas Vondra
> You're right the users can't really take advantage of this - my primary
> motivation was providing a feedback for devs, benchmarking etc. That
> might have been done with DEBUG messages or something, but this seems
> more convenient.
Understood. I'm in favor of adding perfor
On Mon, Jan 20, 2020 at 03:01:36PM -0300, Alvaro Herrera wrote:
On 2020-Jan-20, Tomas Vondra wrote:
On Mon, Jan 20, 2020 at 01:04:33AM +, tsunakawa.ta...@fujitsu.com wrote:
> From: Tomas Vondra
> > One of the stats I occasionally wanted to know are stats for the SLRU
> > stats (we have cou
On 2020-Jan-20, Tomas Vondra wrote:
> On Mon, Jan 20, 2020 at 01:04:33AM +, tsunakawa.ta...@fujitsu.com wrote:
> > From: Tomas Vondra
> > > One of the stats I occasionally wanted to know are stats for the SLRU
> > > stats (we have couple of those - clog, subtrans, ...). So here is a WIP
> > >
On Mon, Jan 20, 2020 at 01:04:33AM +, tsunakawa.ta...@fujitsu.com wrote:
From: Tomas Vondra
One of the stats I occasionally wanted to know are stats for the SLRU
stats (we have couple of those - clog, subtrans, ...). So here is a WIP
version of a patch adding that.
How can users take adva
From: Tomas Vondra
> One of the stats I occasionally wanted to know are stats for the SLRU
> stats (we have couple of those - clog, subtrans, ...). So here is a WIP
> version of a patch adding that.
How can users take advantage of this information? I think we also need the
ability to set the si
recv_bgwriter(PgStat_MsgBgWriter *msg, int len);
+static void pgstat_recv_slru(PgStat_MsgSlru *msg, int len);
static void pgstat_recv_funcstat(PgStat_MsgFuncstat *msg, int len);
static void pgstat_recv_funcpurge(PgStat_MsgFuncpurge *msg, int len);
static void pgstat_recv_recoveryconfl
49 matches
Mail list logo
