From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Resetting spilled txn statistics in pg_stat_replication |
Date: | 2020-07-16 06:53:35 |
Message-ID: | CAA4eK1+CGF-tKRaN8O8YNh4zv+pMgAAhevLa=wspy21kJYTpAA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 10, 2020 at 2:42 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Jul 10, 2020 at 7:23 AM Masahiko Sawada
> <masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
> >
> > On Thu, 9 Jul 2020 at 12:11, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Wed, Jul 8, 2020 at 1:14 PM Masahiko Sawada
> > > <masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
> > > >
> > > >
> > > > I think that using oids has another benefit that we don't need to send
> > > > slot name to the stats collector along with the stats. Since the
> > > > maximum size of slot name is NAMEDATALEN and we don't support the
> > > > pgstat message larger than PGSTAT_MAX_MSG_SIZE (1000 bytes), if the
> > > > user wants to increase NAMEDATALEN they might not be able to build.
> > > >
> > >
> > > I think NAMEDATALEN is used for many other objects as well and I don't
> > > think we want to change it in foreseeable future, so that doesn't
> > > sound to be a good reason to invent OIDs for slots. OTOH, I do
> > > understand it would be better to send OIDs than names for slots but I
> > > am just not sure if it is a good idea to invent a new way to generate
> > > OIDs (which is different from how we do it for other objects in the
> > > system) for this purpose.
> >
> > I'm concerned that there might be users who are using custom
> > PostgreSQL that increased NAMEDATALEN for some reason. But indeed, I
> > also agree with your concerns. So perhaps we can go with the current
> > PoC patch approach as the first version (i.g., sending slot drop
> > message to stats collector). When we need such a unique identifier
> > also for other purposes, we will be able to change this feature so
> > that it uses that identifier for this statistics reporting purpose.
> >
>
> Okay, feel to submit the version atop my revert patch.
>
Attached, please find the rebased version. I have kept prorows as 10
instead of 100 for pg_stat_get_replication_slots because I don't see
much reason for keeping the value more than the default value of
max_replication_slots.
As we are targeting this patch for PG14, so I think we can now add the
functionality to reset the stats as well. What do you think?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
spill_stats_v1.patch | application/octet-stream | 24.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2020-07-16 08:15:01 | Re: Resetting spilled txn statistics in pg_stat_replication |
Previous Message | Dilip Kumar | 2020-07-16 06:52:47 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |