Resetting spilled txn statistics in pg_stat_replication

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

Masahiko Sawada-2
On Fri, 12 Jun 2020 at 12:56, Fujii Masao <[hidden email]> wrote:

>
>
>
> On 2020/06/12 12:21, Amit Kapila wrote:
> > On Thu, Jun 11, 2020 at 7:39 PM Masahiko Sawada
> > <[hidden email]> wrote:
> >>
> >> On Thu, 11 Jun 2020 at 20:02, Amit Kapila <[hidden email]> wrote:
> >>>
> >>> On Thu, Jun 11, 2020 at 3:07 PM Masahiko Sawada
> >>> <[hidden email]> wrote:
> >>>>
> >>>> On Thu, 11 Jun 2020 at 18:11, Amit Kapila <[hidden email]> wrote:
> >>>>>
> >>>>> On Thu, Jun 11, 2020 at 1:46 PM Masahiko Sawada
> >>>>> <[hidden email]> wrote:
> >>>>>>
> >>>>>> On Thu, 11 Jun 2020 at 12:30, Amit Kapila <[hidden email]> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Now, thinking about this again, I am not sure if these stats are
> >>>>>>> directly related to slots. These are stats for logical decoding which
> >>>>>>> can be performed either via WALSender or decoding plugin (via APIs).
> >>>>>>> So, why not have them displayed in a new view like pg_stat_logical (or
> >>>>>>> pg_stat_logical_decoding/pg_stat_logical_replication)?   In future, we
> >>>>>>> will need to add similar stats for streaming of in-progress
> >>>>>>> transactions as well (see patch 0007-Track-statistics-for-streaming at
> >>>>>>> [1]), so having a separate view for these doesn't sound illogical.
> >>>>>>>
> >>>>>>
> >>>>>> I think we need to decide how long we want to remain these statistics
> >>>>>> values. That is, if we were to have such pg_stat_logical view, these
> >>>>>> values would remain until logical decoding finished since I think the
> >>>>>> view would display only running logical decoding. OTOH, if we were to
> >>>>>> correspond these stats to slots, these values would remain beyond
> >>>>>> multiple logical decoding SQL API calls.
> >>>>>>
> >>>>>
> >>>>> I thought of having these till the process that performs these
> >>>>> operations exist.  So for WALSender, the stats will be valid till it
> >>>>> is not restarted due to some reason or when performed via backend, the
> >>>>> stats will be valid till the corresponding backend exits.
> >>>>>
> >>>>
> >>>> The number of rows of that view could be up to (max_backends +
> >>>> max_wal_senders). Is that right? What if different backends used the
> >>>> same replication slot one after the other?
> >>>>
> >>>
> >>> Yeah, it would be tricky if multiple slots are used by the same
> >>> backend.  We could probably track the number of times decoding has
> >>> happened by the session that will probably help us in averaging the
> >>> spill amount.  If we think that the aim is to help users to tune
> >>> logical_decoding_work_mem to avoid frequent spilling or streaming then
> >>> how would maintaining at slot level will help?
> >>
> >> Since the logical decoding intermediate files are written at per slots
> >> directory, I thought that corresponding these statistics to
> >> replication slots is also understandable for users.
> >>
> >
> > What I wanted to know is how will it help users to tune
> > logical_decoding_work_mem?  Different backends can process from the
> > same slot, so it is not clear how user will be able to make any
> > meaning out of those stats.  OTOH, it is easier to see how to make
> > meaning of these stats if we display them w.r.t process.  Basically,
> > we have spill_count and spill_size which can be used to tune
> > logical_decoding_work_mem and also the activity of spilling happens at
> > process level, so it sounds like one-to-one mapping.  I am not telling
> > to rule out maintaining a slot level but trying to see if we can come
> > up with a clear definition.
> >
> >> I was thinking
> >> something like pg_stat_logical_replication_slot view which shows
> >> slot_name and statistics of only logical replication slots. The view
> >> always shows rows as many as existing replication slots regardless of
> >> logical decoding being running. I think there is no big difference in
> >> how users use these statistics values between maintaining at slot
> >> level and at logical decoding level.
> >>
> >> In logical replication case, since we generally don’t support setting
> >> different logical_decoding_work_mem per wal senders, every wal sender
> >> will decode the same WAL stream with the same setting, meaning they
> >> will similarly spill intermediate files.
>
> I was thinking we support that. We can create multiple replication users
> with different logical_decoding_work_mem settings. Also each walsender
> can use logical_decoding_work_mem configured in its user. No?
>

Yes, you're right. I had missed that way.

Regards,

--
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

Masahiko Sawada-2
In reply to this post by akapila
On Fri, 12 Jun 2020 at 12:21, Amit Kapila <[hidden email]> wrote:

>
> On Thu, Jun 11, 2020 at 7:39 PM Masahiko Sawada
> <[hidden email]> wrote:
> >
> > On Thu, 11 Jun 2020 at 20:02, Amit Kapila <[hidden email]> wrote:
> > >
> > > On Thu, Jun 11, 2020 at 3:07 PM Masahiko Sawada
> > > <[hidden email]> wrote:
> > > >
> > > > On Thu, 11 Jun 2020 at 18:11, Amit Kapila <[hidden email]> wrote:
> > > > >
> > > > > On Thu, Jun 11, 2020 at 1:46 PM Masahiko Sawada
> > > > > <[hidden email]> wrote:
> > > > > >
> > > > > > On Thu, 11 Jun 2020 at 12:30, Amit Kapila <[hidden email]> wrote:
> > > > > > >
> > > > > > >
> > > > > > > Now, thinking about this again, I am not sure if these stats are
> > > > > > > directly related to slots. These are stats for logical decoding which
> > > > > > > can be performed either via WALSender or decoding plugin (via APIs).
> > > > > > > So, why not have them displayed in a new view like pg_stat_logical (or
> > > > > > > pg_stat_logical_decoding/pg_stat_logical_replication)?   In future, we
> > > > > > > will need to add similar stats for streaming of in-progress
> > > > > > > transactions as well (see patch 0007-Track-statistics-for-streaming at
> > > > > > > [1]), so having a separate view for these doesn't sound illogical.
> > > > > > >
> > > > > >
> > > > > > I think we need to decide how long we want to remain these statistics
> > > > > > values. That is, if we were to have such pg_stat_logical view, these
> > > > > > values would remain until logical decoding finished since I think the
> > > > > > view would display only running logical decoding. OTOH, if we were to
> > > > > > correspond these stats to slots, these values would remain beyond
> > > > > > multiple logical decoding SQL API calls.
> > > > > >
> > > > >
> > > > > I thought of having these till the process that performs these
> > > > > operations exist.  So for WALSender, the stats will be valid till it
> > > > > is not restarted due to some reason or when performed via backend, the
> > > > > stats will be valid till the corresponding backend exits.
> > > > >
> > > >
> > > > The number of rows of that view could be up to (max_backends +
> > > > max_wal_senders). Is that right? What if different backends used the
> > > > same replication slot one after the other?
> > > >
> > >
> > > Yeah, it would be tricky if multiple slots are used by the same
> > > backend.  We could probably track the number of times decoding has
> > > happened by the session that will probably help us in averaging the
> > > spill amount.  If we think that the aim is to help users to tune
> > > logical_decoding_work_mem to avoid frequent spilling or streaming then
> > > how would maintaining at slot level will help?
> >
> > Since the logical decoding intermediate files are written at per slots
> > directory, I thought that corresponding these statistics to
> > replication slots is also understandable for users.
> >
>
> What I wanted to know is how will it help users to tune
> logical_decoding_work_mem?  Different backends can process from the
> same slot, so it is not clear how user will be able to make any
> meaning out of those stats.

I thought that the user needs to constantly monitor them during one
process is executing logical decoding and to see the increments. I
might not fully understand but I guess the same is true for displaying
them w.r.t. process. Since a process can do logical decoding several
times using the same slot with a different setting, the user will need
to monitor them several times.

> OTOH, it is easier to see how to make
> meaning of these stats if we display them w.r.t process.  Basically,
> we have spill_count and spill_size which can be used to tune
> logical_decoding_work_mem and also the activity of spilling happens at
> process level, so it sounds like one-to-one mapping.

Displaying them w.r.t process also seems a good idea but I'm still
unclear what to display and how long these values are valid. The view
will have the following columns for example?

* pid
* slot_name
* spill_txns
* spill_count
* spill_bytes
* exec_count

Regards,

--
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

akapila
On Fri, Jun 12, 2020 at 11:20 AM Masahiko Sawada
<[hidden email]> wrote:

>
> On Fri, 12 Jun 2020 at 12:21, Amit Kapila <[hidden email]> wrote:
> >
> > > Since the logical decoding intermediate files are written at per slots
> > > directory, I thought that corresponding these statistics to
> > > replication slots is also understandable for users.
> > >
> >
> > What I wanted to know is how will it help users to tune
> > logical_decoding_work_mem?  Different backends can process from the
> > same slot, so it is not clear how user will be able to make any
> > meaning out of those stats.
>
> I thought that the user needs to constantly monitor them during one
> process is executing logical decoding and to see the increments. I
> might not fully understand but I guess the same is true for displaying
> them w.r.t. process. Since a process can do logical decoding several
> times using the same slot with a different setting, the user will need
> to monitor them several times.
>

Yeah, I think we might not be able to get exact measure but if we
divide total_size spilled by exec_count, we will get some rough idea
of what should be the logical_decoding_work_mem for that particular
session.  For ex. consider the logical_decoding_work_mem is 100bytes
for a particular backend and the size spilled by that backend is 100
then I think you can roughly keep it to 200bytes if you want to avoid
spilling.  Similarly one can compute its average value over multiple
executions.  Does this make sense to you?

> > OTOH, it is easier to see how to make
> > meaning of these stats if we display them w.r.t process.  Basically,
> > we have spill_count and spill_size which can be used to tune
> > logical_decoding_work_mem and also the activity of spilling happens at
> > process level, so it sounds like one-to-one mapping.
>
> Displaying them w.r.t process also seems a good idea but I'm still
> unclear what to display and how long these values are valid.
>

I feel till the lifetime of a process if we want to display the values
at process level but I am open to hear others (including yours) views
on this.

> The view
> will have the following columns for example?
>
> * pid
> * slot_name
> * spill_txns
> * spill_count
> * spill_bytes
> * exec_count
>

Yeah, these appear to be what I have in mind.  Note that we can have
multiple entries of the same pid here because of slotname, there is
some value to display slotname but I am not completely sure if that is
a good idea but I am fine if you have a reason to include slotname?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

Magnus Hagander-2


On Fri, Jun 12, 2020 at 10:23 AM Amit Kapila <[hidden email]> wrote:
On Fri, Jun 12, 2020 at 11:20 AM Masahiko Sawada
<[hidden email]> wrote:
>
> On Fri, 12 Jun 2020 at 12:21, Amit Kapila <[hidden email]> wrote:
> >
> > > Since the logical decoding intermediate files are written at per slots
> > > directory, I thought that corresponding these statistics to
> > > replication slots is also understandable for users.
> > >
> >
> > What I wanted to know is how will it help users to tune
> > logical_decoding_work_mem?  Different backends can process from the
> > same slot, so it is not clear how user will be able to make any
> > meaning out of those stats.
>
> I thought that the user needs to constantly monitor them during one
> process is executing logical decoding and to see the increments. I
> might not fully understand but I guess the same is true for displaying
> them w.r.t. process. Since a process can do logical decoding several
> times using the same slot with a different setting, the user will need
> to monitor them several times.
>

Yeah, I think we might not be able to get exact measure but if we
divide total_size spilled by exec_count, we will get some rough idea
of what should be the logical_decoding_work_mem for that particular
session.  For ex. consider the logical_decoding_work_mem is 100bytes
for a particular backend and the size spilled by that backend is 100
then I think you can roughly keep it to 200bytes if you want to avoid
spilling.  Similarly one can compute its average value over multiple
executions.  Does this make sense to you?

The thing that becomes really interesting is to analyze this across time. For example to identify patterns where it always spills at the same time as certain other things are happening. For that usecase, having a "predictable persistence" is important. You may not be able to afford setting logical_decoding_work_mem high enough to cover every possible scenario (if you did, then we would basically not need the spilling..), so you want to track down in relation to the rest of your application exactly when and how this is happening.
 

> > OTOH, it is easier to see how to make
> > meaning of these stats if we display them w.r.t process.  Basically,
> > we have spill_count and spill_size which can be used to tune
> > logical_decoding_work_mem and also the activity of spilling happens at
> > process level, so it sounds like one-to-one mapping.
>
> Displaying them w.r.t process also seems a good idea but I'm still
> unclear what to display and how long these values are valid.
>

I feel till the lifetime of a process if we want to display the values
at process level but I am open to hear others (including yours) views
on this.

The problem with "lifetime of a process" is that it's not predictable. A replication process might "bounce" for any reason, and it is normally not a problem. But if you suddenly lose your stats when you do that, it starts to matter a lot more. Especially when you don't know if it bounced. (Sure you can look at the backend_start time, but that adds a whole different sets of complexitites).


> > The view
> will have the following columns for example?
>
> * pid
> * slot_name
> * spill_txns
> * spill_count
> * spill_bytes
> * exec_count
>

Yeah, these appear to be what I have in mind.  Note that we can have
multiple entries of the same pid here because of slotname, there is
some value to display slotname but I am not completely sure if that is
a good idea but I am fine if you have a reason to include slotname?

Well, it's a general view so you can always GROUP BY that away if you want at reading point?

--
Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

akapila
On Fri, Jun 12, 2020 at 6:11 PM Magnus Hagander <[hidden email]> wrote:
>
> On Fri, Jun 12, 2020 at 10:23 AM Amit Kapila <[hidden email]> wrote:
>>
>
>
> The problem with "lifetime of a process" is that it's not predictable. A replication process might "bounce" for any reason, and it is normally not a problem. But if you suddenly lose your stats when you do that, it starts to matter a lot more. Especially when you don't know if it bounced. (Sure you can look at the backend_start time, but that adds a whole different sets of complexitites).
>

It is not clear to me what is a good way to display the stats for a
process that has exited or bounced due to whatever reason.  OTOH, if
we just display per-slot stats, it is difficult to imagine how the
user can make any sense out of it or in other words how such stats can
be useful to users.

>
> > > The view
>>
>> > will have the following columns for example?
>> >
>> > * pid
>> > * slot_name
>> > * spill_txns
>> > * spill_count
>> > * spill_bytes
>> > * exec_count
>> >
>>
>> Yeah, these appear to be what I have in mind.  Note that we can have
>> multiple entries of the same pid here because of slotname, there is
>> some value to display slotname but I am not completely sure if that is
>> a good idea but I am fine if you have a reason to include slotname?
>
>
> Well, it's a general view so you can always GROUP BY that away if you want at reading point?
>

Okay, that is a valid point.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

Fujii Masao-4


On 2020/06/13 14:23, Amit Kapila wrote:

> On Fri, Jun 12, 2020 at 6:11 PM Magnus Hagander <[hidden email]> wrote:
>>
>> On Fri, Jun 12, 2020 at 10:23 AM Amit Kapila <[hidden email]> wrote:
>>>
>>
>>
>> The problem with "lifetime of a process" is that it's not predictable. A replication process might "bounce" for any reason, and it is normally not a problem. But if you suddenly lose your stats when you do that, it starts to matter a lot more. Especially when you don't know if it bounced. (Sure you can look at the backend_start time, but that adds a whole different sets of complexitites).
>>
>
> It is not clear to me what is a good way to display the stats for a
> process that has exited or bounced due to whatever reason.  OTOH, if
> we just display per-slot stats, it is difficult to imagine how the
> user can make any sense out of it or in other words how such stats can
> be useful to users.

If we allow users to set logical_decoding_work_mem per slot,
maybe the users can tune it directly from the stats?

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

akapila
On Sat, Jun 13, 2020 at 5:07 PM Fujii Masao <[hidden email]> wrote:

>
>
> On 2020/06/13 14:23, Amit Kapila wrote:
> > On Fri, Jun 12, 2020 at 6:11 PM Magnus Hagander <[hidden email]> wrote:
> >>
> >> On Fri, Jun 12, 2020 at 10:23 AM Amit Kapila <[hidden email]> wrote:
> >>>
> >>
> >>
> >> The problem with "lifetime of a process" is that it's not predictable. A replication process might "bounce" for any reason, and it is normally not a problem. But if you suddenly lose your stats when you do that, it starts to matter a lot more. Especially when you don't know if it bounced. (Sure you can look at the backend_start time, but that adds a whole different sets of complexitites).
> >>
> >
> > It is not clear to me what is a good way to display the stats for a
> > process that has exited or bounced due to whatever reason.  OTOH, if
> > we just display per-slot stats, it is difficult to imagine how the
> > user can make any sense out of it or in other words how such stats can
> > be useful to users.
>
> If we allow users to set logical_decoding_work_mem per slot,
> maybe the users can tune it directly from the stats?
>

How will it behave when same slot is used from multiple sessions?  I
think it will be difficult to make sense of the stats for slots unless
we also somehow see which process has lead to that stats and if we do
so then there won't be much difference w.r.t what we can do now?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

Masahiko Sawada-2
In reply to this post by akapila
On Sat, 13 Jun 2020 at 14:23, Amit Kapila <[hidden email]> wrote:

>
> On Fri, Jun 12, 2020 at 6:11 PM Magnus Hagander <[hidden email]> wrote:
> >
> > On Fri, Jun 12, 2020 at 10:23 AM Amit Kapila <[hidden email]> wrote:
> >>
> >
> >
> > The problem with "lifetime of a process" is that it's not predictable. A replication process might "bounce" for any reason, and it is normally not a problem. But if you suddenly lose your stats when you do that, it starts to matter a lot more. Especially when you don't know if it bounced. (Sure you can look at the backend_start time, but that adds a whole different sets of complexitites).
> >
>
> It is not clear to me what is a good way to display the stats for a
> process that has exited or bounced due to whatever reason.  OTOH, if
> we just display per-slot stats, it is difficult to imagine how the
> user can make any sense out of it or in other words how such stats can
> be useful to users.

If we have the reset function, the user can reset before doing logical
decoding so that the user can use the stats directly. Or I think we
can automatically reset the stats when logical decoding is performed
with different logical_decoding_work_mem value than the previous one.
In either way, since the stats correspond to the logical decoding
using the same slot with the same parameter value the user can use
them directly.

Regards,

--
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

akapila
On Wed, Jun 17, 2020 at 1:34 PM Masahiko Sawada
<[hidden email]> wrote:

>
> On Sat, 13 Jun 2020 at 14:23, Amit Kapila <[hidden email]> wrote:
> >
> > On Fri, Jun 12, 2020 at 6:11 PM Magnus Hagander <[hidden email]> wrote:
> > >
> > > On Fri, Jun 12, 2020 at 10:23 AM Amit Kapila <[hidden email]> wrote:
> > >>
> > >
> > >
> > > The problem with "lifetime of a process" is that it's not predictable. A replication process might "bounce" for any reason, and it is normally not a problem. But if you suddenly lose your stats when you do that, it starts to matter a lot more. Especially when you don't know if it bounced. (Sure you can look at the backend_start time, but that adds a whole different sets of complexitites).
> > >
> >
> > It is not clear to me what is a good way to display the stats for a
> > process that has exited or bounced due to whatever reason.  OTOH, if
> > we just display per-slot stats, it is difficult to imagine how the
> > user can make any sense out of it or in other words how such stats can
> > be useful to users.
>
> If we have the reset function, the user can reset before doing logical
> decoding so that the user can use the stats directly. Or I think we
> can automatically reset the stats when logical decoding is performed
> with different logical_decoding_work_mem value than the previous one.
>

I had written above in the context of persisting these stats.  I mean
to say if the process has bounced or server has restarted then the
previous stats might not make much sense because we were planning to
use pid [1], so the stats from process that has exited might not make
much sense or do you think that is okay?  If we don't want to persist
and the lifetime of these stats is till the process is alive then we
are fine.


[1] - https://www.postgresql.org/message-id/CA%2Bfd4k5nqeFdhpnCULpTh9TR%2B15rHZSbz0SDC6sZhr_v99SeKA%40mail.gmail.com

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

Masahiko Sawada-2
On Wed, 17 Jun 2020 at 20:14, Amit Kapila <[hidden email]> wrote:

>
> On Wed, Jun 17, 2020 at 1:34 PM Masahiko Sawada
> <[hidden email]> wrote:
> >
> > On Sat, 13 Jun 2020 at 14:23, Amit Kapila <[hidden email]> wrote:
> > >
> > > On Fri, Jun 12, 2020 at 6:11 PM Magnus Hagander <[hidden email]> wrote:
> > > >
> > > > On Fri, Jun 12, 2020 at 10:23 AM Amit Kapila <[hidden email]> wrote:
> > > >>
> > > >
> > > >
> > > > The problem with "lifetime of a process" is that it's not predictable. A replication process might "bounce" for any reason, and it is normally not a problem. But if you suddenly lose your stats when you do that, it starts to matter a lot more. Especially when you don't know if it bounced. (Sure you can look at the backend_start time, but that adds a whole different sets of complexitites).
> > > >
> > >
> > > It is not clear to me what is a good way to display the stats for a
> > > process that has exited or bounced due to whatever reason.  OTOH, if
> > > we just display per-slot stats, it is difficult to imagine how the
> > > user can make any sense out of it or in other words how such stats can
> > > be useful to users.
> >
> > If we have the reset function, the user can reset before doing logical
> > decoding so that the user can use the stats directly. Or I think we
> > can automatically reset the stats when logical decoding is performed
> > with different logical_decoding_work_mem value than the previous one.
> >
>
> I had written above in the context of persisting these stats.  I mean
> to say if the process has bounced or server has restarted then the
> previous stats might not make much sense because we were planning to
> use pid [1], so the stats from process that has exited might not make
> much sense or do you think that is okay?  If we don't want to persist
> and the lifetime of these stats is till the process is alive then we
> are fine.
>

Sorry for confusing you. The above my idea is about having the stats
per slots. That is, we add spill_txns, spill_count and spill_bytes to
pg_replication_slots or a new view pg_stat_logical_replication_slots
with some columns: slot_name plus these stats columns and stats_reset.
The idea is that the stats values accumulate until either the slot is
dropped, the server crashed, the user executes the reset function, or
logical decoding is performed with different logical_decoding_work_mem
value than the previous time. In other words, the stats values are
reset in either case. That way, I think the stats values always
correspond to logical decoding using the same slot with the same
logical_decoding_work_mem value.

Regards,

--
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

akapila
On Thu, Jun 18, 2020 at 8:01 AM Masahiko Sawada
<[hidden email]> wrote:

>
> On Wed, 17 Jun 2020 at 20:14, Amit Kapila <[hidden email]> wrote:
> >
> >
> > I had written above in the context of persisting these stats.  I mean
> > to say if the process has bounced or server has restarted then the
> > previous stats might not make much sense because we were planning to
> > use pid [1], so the stats from process that has exited might not make
> > much sense or do you think that is okay?  If we don't want to persist
> > and the lifetime of these stats is till the process is alive then we
> > are fine.
> >
>
> Sorry for confusing you. The above my idea is about having the stats
> per slots. That is, we add spill_txns, spill_count and spill_bytes to
> pg_replication_slots or a new view pg_stat_logical_replication_slots
> with some columns: slot_name plus these stats columns and stats_reset.
> The idea is that the stats values accumulate until either the slot is
> dropped, the server crashed, the user executes the reset function, or
> logical decoding is performed with different logical_decoding_work_mem
> value than the previous time. In other words, the stats values are
> reset in either case. That way, I think the stats values always
> correspond to logical decoding using the same slot with the same
> logical_decoding_work_mem value.
>

What if the decoding has been performed by multiple backends using the
same slot?  In that case, it will be difficult to make the judgment
for the value of logical_decoding_work_mem based on stats.  It would
make sense if we provide a way to set logical_decoding_work_mem for a
slot but not sure if that is better than what we have now.

What problems do we see in displaying these for each process?  I think
users might want to see the stats for the exited processes or after
server restart but I think both of those are not even possible today.
I think the stats are available till the corresponding WALSender
process is active.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

Tomas Vondra-4
In reply to this post by Masahiko Sawada-2
Hi,

Sorry for neglecting this thread for the last couple days ...

In general, I agree it's somewhat unfortunate the stats are reset when
the walsender exits. This was mostly fine for tuning of the spilling
(change value -> restart -> see stats) but for proper monitoring this
is somewhat problematic. I simply considered these fields somewhat
similar to lag monitoring, not from the "monitoring" POV.


On Thu, Jun 11, 2020 at 11:09:00PM +0900, Masahiko Sawada wrote:

>
> ...
>
>Since the logical decoding intermediate files are written at per slots
>directory, I thought that corresponding these statistics to
>replication slots is also understandable for users. I was thinking
>something like pg_stat_logical_replication_slot view which shows
>slot_name and statistics of only logical replication slots. The view
>always shows rows as many as existing replication slots regardless of
>logical decoding being running. I think there is no big difference in
>how users use these statistics values between maintaining at slot
>level and at logical decoding level.
>
>In logical replication case, since we generally don’t support setting
>different logical_decoding_work_mem per wal senders, every wal sender
>will decode the same WAL stream with the same setting, meaning they
>will similarly spill intermediate files. Maybe the same is true
>statistics of streaming. So having these statistics per logical
>replication might not help as of now.
>

I think the idea to track these stats per replication slot (rather than
per walsender) is the right approach. We should extend statistics
collector to keep one entry per replication slot and have a new stats
view called e.g. pg_stat_replication_slots, which could be reset just
like other stats in the collector.

I don't quite understand the discussion about different backends using
logical_decoding_work_mem - why would this be an issue? Surely we have
this exact issue e.g. with tracking index vs. sequential scans and GUCs
like random_page_cost. That can change over time too, different backends
may use different values, and yet we don't worry about resetting the
number of index scans for a table etc.


regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

Tomas Vondra-4
In reply to this post by akapila
On Thu, Jun 18, 2020 at 12:21:17PM +0530, Amit Kapila wrote:

>On Thu, Jun 18, 2020 at 8:01 AM Masahiko Sawada
><[hidden email]> wrote:
>>
>> On Wed, 17 Jun 2020 at 20:14, Amit Kapila <[hidden email]> wrote:
>> >
>> >
>> > I had written above in the context of persisting these stats.  I mean
>> > to say if the process has bounced or server has restarted then the
>> > previous stats might not make much sense because we were planning to
>> > use pid [1], so the stats from process that has exited might not make
>> > much sense or do you think that is okay?  If we don't want to persist
>> > and the lifetime of these stats is till the process is alive then we
>> > are fine.
>> >
>>
>> Sorry for confusing you. The above my idea is about having the stats
>> per slots. That is, we add spill_txns, spill_count and spill_bytes to
>> pg_replication_slots or a new view pg_stat_logical_replication_slots
>> with some columns: slot_name plus these stats columns and stats_reset.
>> The idea is that the stats values accumulate until either the slot is
>> dropped, the server crashed, the user executes the reset function, or
>> logical decoding is performed with different logical_decoding_work_mem
>> value than the previous time. In other words, the stats values are
>> reset in either case. That way, I think the stats values always
>> correspond to logical decoding using the same slot with the same
>> logical_decoding_work_mem value.
>>
>
>What if the decoding has been performed by multiple backends using the
>same slot?  In that case, it will be difficult to make the judgment
>for the value of logical_decoding_work_mem based on stats.  It would
>make sense if we provide a way to set logical_decoding_work_mem for a
>slot but not sure if that is better than what we have now.
>
>What problems do we see in displaying these for each process?  I think
>users might want to see the stats for the exited processes or after
>server restart but I think both of those are not even possible today.
>I think the stats are available till the corresponding WALSender
>process is active.
>

I don't quite see what the problem is. We're in this exact position with
many other stats we track and various GUCs. If you decide to tune the
setting for a particular slot, you simply need to be careful which
backends decode the slot and what GUC values they used.

But I don't think this situation (multiple backends decoding the same
slot with different logical_decoding_work_mem values) is very common. In
most cases the backends/walsenders will all use the same value. If you
change that, you better remember that.

I really think we should not be inventing something that automatically
resets the stats when someone happens to change the GUC.


regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

akapila
On Sun, Jun 21, 2020 at 3:27 AM Tomas Vondra
<[hidden email]> wrote:

>
> On Thu, Jun 18, 2020 at 12:21:17PM +0530, Amit Kapila wrote:
> >On Thu, Jun 18, 2020 at 8:01 AM Masahiko Sawada
> ><[hidden email]> wrote:
> >>
> >> On Wed, 17 Jun 2020 at 20:14, Amit Kapila <[hidden email]> wrote:
> >> >
> >> >
> >> > I had written above in the context of persisting these stats.  I mean
> >> > to say if the process has bounced or server has restarted then the
> >> > previous stats might not make much sense because we were planning to
> >> > use pid [1], so the stats from process that has exited might not make
> >> > much sense or do you think that is okay?  If we don't want to persist
> >> > and the lifetime of these stats is till the process is alive then we
> >> > are fine.
> >> >
> >>
> >> Sorry for confusing you. The above my idea is about having the stats
> >> per slots. That is, we add spill_txns, spill_count and spill_bytes to
> >> pg_replication_slots or a new view pg_stat_logical_replication_slots
> >> with some columns: slot_name plus these stats columns and stats_reset.
> >> The idea is that the stats values accumulate until either the slot is
> >> dropped, the server crashed, the user executes the reset function, or
> >> logical decoding is performed with different logical_decoding_work_mem
> >> value than the previous time. In other words, the stats values are
> >> reset in either case. That way, I think the stats values always
> >> correspond to logical decoding using the same slot with the same
> >> logical_decoding_work_mem value.
> >>
> >
> >What if the decoding has been performed by multiple backends using the
> >same slot?  In that case, it will be difficult to make the judgment
> >for the value of logical_decoding_work_mem based on stats.  It would
> >make sense if we provide a way to set logical_decoding_work_mem for a
> >slot but not sure if that is better than what we have now.
> >
> >What problems do we see in displaying these for each process?  I think
> >users might want to see the stats for the exited processes or after
> >server restart but I think both of those are not even possible today.
> >I think the stats are available till the corresponding WALSender
> >process is active.
> >
>
> I don't quite see what the problem is. We're in this exact position with
> many other stats we track and various GUCs. If you decide to tune the
> setting for a particular slot, you simply need to be careful which
> backends decode the slot and what GUC values they used.
>

What problem do you if we allow it to display per-process (WALSender
or backend)?  They are incurred by the WALSender or by backends so
displaying them accordingly seems more straightforward and logical to
me.

As of now, we don't allow it to be set for a slot, so it won't be
convenient for the user to tune it per slot.  I think we can allow to
set it per-slot but not sure if there is any benefit for the same.

> I really think we should not be inventing something that automatically
> resets the stats when someone happens to change the GUC.
>

I agree with that.


--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

akapila
On Mon, Jun 22, 2020 at 8:22 AM Amit Kapila <[hidden email]> wrote:

>
> On Sun, Jun 21, 2020 at 3:27 AM Tomas Vondra
> <[hidden email]> wrote:
> >
> > On Thu, Jun 18, 2020 at 12:21:17PM +0530, Amit Kapila wrote:
> > >On Thu, Jun 18, 2020 at 8:01 AM Masahiko Sawada
> > ><[hidden email]> wrote:
> > >>
> > >> On Wed, 17 Jun 2020 at 20:14, Amit Kapila <[hidden email]> wrote:
> > >> >
> > >> >
> > >> > I had written above in the context of persisting these stats.  I mean
> > >> > to say if the process has bounced or server has restarted then the
> > >> > previous stats might not make much sense because we were planning to
> > >> > use pid [1], so the stats from process that has exited might not make
> > >> > much sense or do you think that is okay?  If we don't want to persist
> > >> > and the lifetime of these stats is till the process is alive then we
> > >> > are fine.
> > >> >
> > >>
> > >> Sorry for confusing you. The above my idea is about having the stats
> > >> per slots. That is, we add spill_txns, spill_count and spill_bytes to
> > >> pg_replication_slots or a new view pg_stat_logical_replication_slots
> > >> with some columns: slot_name plus these stats columns and stats_reset.
> > >> The idea is that the stats values accumulate until either the slot is
> > >> dropped, the server crashed, the user executes the reset function, or
> > >> logical decoding is performed with different logical_decoding_work_mem
> > >> value than the previous time. In other words, the stats values are
> > >> reset in either case. That way, I think the stats values always
> > >> correspond to logical decoding using the same slot with the same
> > >> logical_decoding_work_mem value.
> > >>
> > >
> > >What if the decoding has been performed by multiple backends using the
> > >same slot?  In that case, it will be difficult to make the judgment
> > >for the value of logical_decoding_work_mem based on stats.  It would
> > >make sense if we provide a way to set logical_decoding_work_mem for a
> > >slot but not sure if that is better than what we have now.
> > >
> > >What problems do we see in displaying these for each process?  I think
> > >users might want to see the stats for the exited processes or after
> > >server restart but I think both of those are not even possible today.
> > >I think the stats are available till the corresponding WALSender
> > >process is active.
> > >
> >
> > I don't quite see what the problem is. We're in this exact position with
> > many other stats we track and various GUCs. If you decide to tune the
> > setting for a particular slot, you simply need to be careful which
> > backends decode the slot and what GUC values they used.
> >
>
> What problem do you if we allow it to display per-process (WALSender
> or backend)?  They are incurred by the WALSender or by backends so
> displaying them accordingly seems more straightforward and logical to
> me.
>
> As of now, we don't allow it to be set for a slot, so it won't be
> convenient for the user to tune it per slot.  I think we can allow to
> set it per-slot but not sure if there is any benefit for the same.
>

If we display stats as discussed in email [1] (pid, slot_name,
spill_txns, spill_count, etc.), then we can even find the stats w.r.t
each slot.


[1] - https://www.postgresql.org/message-id/CA%2Bfd4k5nqeFdhpnCULpTh9TR%2B15rHZSbz0SDC6sZhr_v99SeKA%40mail.gmail.com

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

Masahiko Sawada-2
In reply to this post by Tomas Vondra-4
On Sun, 21 Jun 2020 at 06:57, Tomas Vondra <[hidden email]> wrote:

>
> On Thu, Jun 18, 2020 at 12:21:17PM +0530, Amit Kapila wrote:
> >On Thu, Jun 18, 2020 at 8:01 AM Masahiko Sawada
> ><[hidden email]> wrote:
> >>
> >> On Wed, 17 Jun 2020 at 20:14, Amit Kapila <[hidden email]> wrote:
> >> >
> >> >
> >> > I had written above in the context of persisting these stats.  I mean
> >> > to say if the process has bounced or server has restarted then the
> >> > previous stats might not make much sense because we were planning to
> >> > use pid [1], so the stats from process that has exited might not make
> >> > much sense or do you think that is okay?  If we don't want to persist
> >> > and the lifetime of these stats is till the process is alive then we
> >> > are fine.
> >> >
> >>
> >> Sorry for confusing you. The above my idea is about having the stats
> >> per slots. That is, we add spill_txns, spill_count and spill_bytes to
> >> pg_replication_slots or a new view pg_stat_logical_replication_slots
> >> with some columns: slot_name plus these stats columns and stats_reset.
> >> The idea is that the stats values accumulate until either the slot is
> >> dropped, the server crashed, the user executes the reset function, or
> >> logical decoding is performed with different logical_decoding_work_mem
> >> value than the previous time. In other words, the stats values are
> >> reset in either case. That way, I think the stats values always
> >> correspond to logical decoding using the same slot with the same
> >> logical_decoding_work_mem value.
> >>
> >
> >What if the decoding has been performed by multiple backends using the
> >same slot?  In that case, it will be difficult to make the judgment
> >for the value of logical_decoding_work_mem based on stats.  It would
> >make sense if we provide a way to set logical_decoding_work_mem for a
> >slot but not sure if that is better than what we have now.
> >

I thought that the stats are relevant to what
logical_decoding_work_mem value was but not with who performed logical
decoding. So even if multiple backends perform logical decoding using
the same slot, the user can directly use stats as long as
logical_decoding_work_mem value doesn’t change.

> >What problems do we see in displaying these for each process?  I think
> >users might want to see the stats for the exited processes or after
> >server restart but I think both of those are not even possible today.
> >I think the stats are available till the corresponding WALSender
> >process is active.

I might want to see the stats for the exited processes or after server
restart. But I'm inclined to agree with displaying the stats per
process if the stats are displayed on a separate view (e.g.
pg_stat_replication_slots).

> >
>
> I don't quite see what the problem is. We're in this exact position with
> many other stats we track and various GUCs. If you decide to tune the
> setting for a particular slot, you simply need to be careful which
> backends decode the slot and what GUC values they used.
>
> But I don't think this situation (multiple backends decoding the same
> slot with different logical_decoding_work_mem values) is very common. In
> most cases the backends/walsenders will all use the same value. If you
> change that, you better remember that.
>
> I really think we should not be inventing something that automatically
> resets the stats when someone happens to change the GUC.

Agreed. But what I thought is more simple; storing the
logical_decoding_work_mem value along with the stats into a logical
replication slot and resetting the stats if the
logical_decoding_work_mem value is different than the stored value
when performing logical decoding.

Regards,

--
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

akapila
On Tue, Jun 23, 2020 at 9:32 AM Masahiko Sawada
<[hidden email]> wrote:

>
> On Sun, 21 Jun 2020 at 06:57, Tomas Vondra <[hidden email]> wrote:
> >
> > >
> > >What if the decoding has been performed by multiple backends using the
> > >same slot?  In that case, it will be difficult to make the judgment
> > >for the value of logical_decoding_work_mem based on stats.  It would
> > >make sense if we provide a way to set logical_decoding_work_mem for a
> > >slot but not sure if that is better than what we have now.
> > >
>
> I thought that the stats are relevant to what
> logical_decoding_work_mem value was but not with who performed logical
> decoding. So even if multiple backends perform logical decoding using
> the same slot, the user can directly use stats as long as
> logical_decoding_work_mem value doesn’t change.
>

I think if you maintain these stats at the slot level, you probably
need to use spinlock or atomic ops in order to update those as slots
can be used from multiple backends whereas currently, we don't need
that.

> > >What problems do we see in displaying these for each process?  I think
> > >users might want to see the stats for the exited processes or after
> > >server restart but I think both of those are not even possible today.
> > >I think the stats are available till the corresponding WALSender
> > >process is active.
>
> I might want to see the stats for the exited processes or after server
> restart. But I'm inclined to agree with displaying the stats per
> process if the stats are displayed on a separate view (e.g.
> pg_stat_replication_slots).
>

Yeah, as told previously, this makes more sense to me.

Do you think we should try to write a POC patch using a per-process
entry approach and see what difficulties we are facing and does it
give the stats in a way we are imagining but OTOH, we can wait for
some more to see if there is clear winner approach here?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

Tomas Vondra-4
On Tue, Jun 23, 2020 at 10:58:18AM +0530, Amit Kapila wrote:

>On Tue, Jun 23, 2020 at 9:32 AM Masahiko Sawada
><[hidden email]> wrote:
>>
>> On Sun, 21 Jun 2020 at 06:57, Tomas Vondra <[hidden email]> wrote:
>> >
>> > >
>> > >What if the decoding has been performed by multiple backends using the
>> > >same slot?  In that case, it will be difficult to make the judgment
>> > >for the value of logical_decoding_work_mem based on stats.  It would
>> > >make sense if we provide a way to set logical_decoding_work_mem for a
>> > >slot but not sure if that is better than what we have now.
>> > >
>>
>> I thought that the stats are relevant to what
>> logical_decoding_work_mem value was but not with who performed logical
>> decoding. So even if multiple backends perform logical decoding using
>> the same slot, the user can directly use stats as long as
>> logical_decoding_work_mem value doesn’t change.
>>
>
>I think if you maintain these stats at the slot level, you probably
>need to use spinlock or atomic ops in order to update those as slots
>can be used from multiple backends whereas currently, we don't need
>that.

IMHO storing the stats in the slot itself is a bad idea. We have the
statistics collector for exactly this purpose, and it's receiving data
over UDP without any extra locking etc.

>
>> > >What problems do we see in displaying these for each process?  I think
>> > >users might want to see the stats for the exited processes or after
>> > >server restart but I think both of those are not even possible today.
>> > >I think the stats are available till the corresponding WALSender
>> > >process is active.
>>
>> I might want to see the stats for the exited processes or after server
>> restart. But I'm inclined to agree with displaying the stats per
>> process if the stats are displayed on a separate view (e.g.
>> pg_stat_replication_slots).
>>
>
>Yeah, as told previously, this makes more sense to me.
>
>Do you think we should try to write a POC patch using a per-process
>entry approach and see what difficulties we are facing and does it
>give the stats in a way we are imagining but OTOH, we can wait for
>some more to see if there is clear winner approach here?
>

I may be missing something obvious, but I still see no point in tracking
per-process stats. We don't have that for other stats, and I'm not sure
how common is the scenario when a given slot is decoded by many
backends. I'd say vast majority of cases are simply running decoding
from a walsender, which may occasionally restart, but I doubt the users
are interested in per-pid data - they probably want aggregated data.

Can someone explain a plausible scenario for which tracking per-process
stats would be needed, and simply computing deltas would not work? How
will you know which old PID is which, what will you do when a PID is
reused, and so on?


regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

akapila
On Tue, Jun 23, 2020 at 3:48 PM Tomas Vondra
<[hidden email]> wrote:

>
> On Tue, Jun 23, 2020 at 10:58:18AM +0530, Amit Kapila wrote:
> >On Tue, Jun 23, 2020 at 9:32 AM Masahiko Sawada
> ><[hidden email]> wrote:
> >>
> >> On Sun, 21 Jun 2020 at 06:57, Tomas Vondra <[hidden email]> wrote:
> >> >
> >> > >
> >> > >What if the decoding has been performed by multiple backends using the
> >> > >same slot?  In that case, it will be difficult to make the judgment
> >> > >for the value of logical_decoding_work_mem based on stats.  It would
> >> > >make sense if we provide a way to set logical_decoding_work_mem for a
> >> > >slot but not sure if that is better than what we have now.
> >> > >
> >>
> >> I thought that the stats are relevant to what
> >> logical_decoding_work_mem value was but not with who performed logical
> >> decoding. So even if multiple backends perform logical decoding using
> >> the same slot, the user can directly use stats as long as
> >> logical_decoding_work_mem value doesn’t change.
> >>
> >
> >I think if you maintain these stats at the slot level, you probably
> >need to use spinlock or atomic ops in order to update those as slots
> >can be used from multiple backends whereas currently, we don't need
> >that.
>
> IMHO storing the stats in the slot itself is a bad idea. We have the
> statistics collector for exactly this purpose, and it's receiving data
> over UDP without any extra locking etc.
> >
> >> > >What problems do we see in displaying these for each process?  I think
> >> > >users might want to see the stats for the exited processes or after
> >> > >server restart but I think both of those are not even possible today.
> >> > >I think the stats are available till the corresponding WALSender
> >> > >process is active.
> >>
> >> I might want to see the stats for the exited processes or after server
> >> restart. But I'm inclined to agree with displaying the stats per
> >> process if the stats are displayed on a separate view (e.g.
> >> pg_stat_replication_slots).
> >>
> >
> >Yeah, as told previously, this makes more sense to me.
> >
> >Do you think we should try to write a POC patch using a per-process
> >entry approach and see what difficulties we are facing and does it
> >give the stats in a way we are imagining but OTOH, we can wait for
> >some more to see if there is clear winner approach here?
> >
>
> I may be missing something obvious, but I still see no point in tracking
> per-process stats. We don't have that for other stats,
>

Won't we display per-process information in pg_stat_replication?
These stats are currently displayed in that view and one of the
shortcomings was that it won't display these stats when we decode via
backend.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


Reply | Threaded
Open this post in threaded view
|

Re: Resetting spilled txn statistics in pg_stat_replication

akapila
On Tue, Jun 23, 2020 at 6:39 PM Amit Kapila <[hidden email]> wrote:

>
> On Tue, Jun 23, 2020 at 3:48 PM Tomas Vondra
> <[hidden email]> wrote:
> >
> > On Tue, Jun 23, 2020 at 10:58:18AM +0530, Amit Kapila wrote:
> > >On Tue, Jun 23, 2020 at 9:32 AM Masahiko Sawada
> > ><[hidden email]> wrote:
> > >>
> > >> On Sun, 21 Jun 2020 at 06:57, Tomas Vondra <[hidden email]> wrote:
> > >> >
> > >> > >
> > >> > >What if the decoding has been performed by multiple backends using the
> > >> > >same slot?  In that case, it will be difficult to make the judgment
> > >> > >for the value of logical_decoding_work_mem based on stats.  It would
> > >> > >make sense if we provide a way to set logical_decoding_work_mem for a
> > >> > >slot but not sure if that is better than what we have now.
> > >> > >
> > >>
> > >> I thought that the stats are relevant to what
> > >> logical_decoding_work_mem value was but not with who performed logical
> > >> decoding. So even if multiple backends perform logical decoding using
> > >> the same slot, the user can directly use stats as long as
> > >> logical_decoding_work_mem value doesn’t change.
> > >>

Today, I thought about it again, and if we consider the point that
logical_decoding_work_mem value doesn’t change much then having the
stats at slot-level would also allow computing
logical_decoding_work_mem based on stats.  Do you think it is a
reasonable assumption that users won't change
logical_decoding_work_mem for different processes (WALSender, etc.)?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


123