Hi,
On 2023-05-24 05:53:51 +, Zhijie Hou (Fujitsu) wrote:
> On Tuesday, May 23, 2023 1:53 AM Andres Freund wrote:
> > On 2023-05-22 12:15:07 +, Zhijie Hou (Fujitsu) wrote:
> > > About "a backend doing logical decoding", do you mean the case when a
> > user
> > > start a backend and invoke
On Tuesday, May 23, 2023 1:53 AM Andres Freund wrote:
> On 2023-05-22 12:15:07 +, Zhijie Hou (Fujitsu) wrote:
> > About "a backend doing logical decoding", do you mean the case when a
> user
> > start a backend and invoke pg_logical_slot_get_changes() to do the logical
> > decoding ? If so, it
Hi,
On 2023-05-22 12:15:07 +, Zhijie Hou (Fujitsu) wrote:
> About "a backend doing logical decoding", do you mean the case when a user
> start a backend and invoke pg_logical_slot_get_changes() to do the logical
> decoding ? If so, it seems the logical decoding in a backend won't be waked up
>
Hi,
On Monday, May 22, 2023 12:11 AM Andres Freund wrote:
> On 2023-05-19 12:07:56 +0900, Kyotaro Horiguchi wrote:
> > At Thu, 18 May 2023 20:11:11 +0530, Bharath Rupireddy
> wrote in
> > > > > +
> ConditionVariableInit(&WalSndCtl->physicalWALSndCV);
> > > > > + ConditionVariableInit
Hi,
On 2023-05-18 20:11:11 +0530, Bharath Rupireddy wrote:
> Please find the attached v4 patch addressing the review comment (not
> the fastpath one).
I pushed a mildly edited version of this. I didn't like the name of the CVs
much, so I renamed them to wal_flush_cv/wal_replay_cv. I also did some
Hi,
On 2023-05-19 12:07:56 +0900, Kyotaro Horiguchi wrote:
> At Thu, 18 May 2023 20:11:11 +0530, Bharath Rupireddy
> wrote in
> > > > + ConditionVariableInit(&WalSndCtl->physicalWALSndCV);
> > > > + ConditionVariableInit(&WalSndCtl->logicalWALSndCV);
> > >
> > > It's not
On Friday, May 19, 2023 11:08 AM Kyotaro Horiguchi
wrote:
> At Thu, 18 May 2023 20:11:11 +0530, Bharath Rupireddy
> wrote in
> > > > + ConditionVariableInit(&WalSndCtl->physicalWALSndCV);
> > > > + ConditionVariableInit(&WalSndCtl->logicalWALSndCV);
> > >
> > > It's not o
At Thu, 18 May 2023 20:11:11 +0530, Bharath Rupireddy
wrote in
> > > + ConditionVariableInit(&WalSndCtl->physicalWALSndCV);
> > > + ConditionVariableInit(&WalSndCtl->logicalWALSndCV);
> >
> > It's not obvious to me that it's worth having two CVs, because it's more
> > exp
On Thu, May 18, 2023 at 1:23 AM Andres Freund wrote:
>
> On 2023-05-15 20:09:00 +0530, Bharath Rupireddy wrote:
> > > [1]
> > > max_wal_senders = 100
> > > before regression(ms)after regression(ms)v2 patch(ms)
> > > 13394.4013 14141.2615 13
Hi,
On 2023-05-17 12:53:15 -0700, Andres Freund wrote:
> I'll try to come up with a benchmark without the issues I pointed out in
> https://postgr.es/m/20230517194331.ficfy5brpfq5lrmz%40awork3.anarazel.de
Here we go:
setup:
create primary
SELECT pg_create_physical_replication_slot('reserve', tr
Hi,
Thanks for working on the patch!
On 2023-05-15 20:09:00 +0530, Bharath Rupireddy wrote:
> > [1]
> > max_wal_senders = 100
> > before regression(ms)after regression(ms)v2 patch(ms)
> > 13394.4013 14141.2615 13455.2543
> > Compared with
On Wed, 2023-05-17 at 12:34 -0700, Andres Freund wrote:
> I understood Jeff's proposal to just have an early exit if there are
> no
> walsenders connected at all.
My suggestion was we early exit unless there is at least one *waiting*
walsender of the appropriate type. In other words, increment the
Hi,
On 2023-05-11 09:42:39 +, Zhijie Hou (Fujitsu) wrote:
> I did some simple tests for this to see the performance impact on
> the streaming replication, just share it here for reference.
>
> 1) sync primary-standby setup, load data on primary and count the time spent
> on
> replication.
Hi,
On 2023-05-10 08:39:08 +0200, Drouvot, Bertrand wrote:
> On 5/9/23 11:00 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2023-05-09 13:38:24 -0700, Jeff Davis wrote:
> > > On Tue, 2023-05-09 at 12:02 -0700, Andres Freund wrote:
> > > > I don't think the approach of not having any sort of "registr
Hi,
On 5/15/23 4:39 PM, Bharath Rupireddy wrote:
On Mon, May 15, 2023 at 6:14 PM Masahiko Sawada wrote:
On Mon, May 15, 2023 at 1:49 PM Thomas Munro wrote:
Do we need to add an open item for this issue in
https://wiki.postgresql.org/wiki/PostgreSQL_16_Open_Items? If yes, can
anyone in this
On Mon, May 15, 2023 at 6:14 PM Masahiko Sawada wrote:
>
> On Mon, May 15, 2023 at 1:49 PM Thomas Munro wrote:
> >
> > On Fri, May 12, 2023 at 11:58 PM Bharath Rupireddy
> > wrote:
> > > Andres, rightly put it - 'mis-using' CV infrastructure. It is simple,
> > > works, and makes the WalSndWakeup
On Mon, May 15, 2023 at 1:49 PM Thomas Munro wrote:
>
> On Fri, May 12, 2023 at 11:58 PM Bharath Rupireddy
> wrote:
> > Andres, rightly put it - 'mis-using' CV infrastructure. It is simple,
> > works, and makes the WalSndWakeup() easy solving the performance
> > regression.
>
> Yeah, this seems O
Hi,
On 5/15/23 4:19 AM, Zhijie Hou (Fujitsu) wrote:
On Friday, May 12, 2023 7:58 PM Bharath Rupireddy
wrote:
On Wed, May 10, 2023 at 3:23 PM Drouvot, Bertrand
That's not the case with the attached v2 patch. Please have a look.
Thanks for V2! It does look good to me and I like the fact t
On Fri, May 12, 2023 at 11:58 PM Bharath Rupireddy
wrote:
> Andres, rightly put it - 'mis-using' CV infrastructure. It is simple,
> works, and makes the WalSndWakeup() easy solving the performance
> regression.
Yeah, this seems OK, and better than the complicated alternatives. If
one day we want
On Friday, May 12, 2023 7:58 PM Bharath Rupireddy
wrote:
>
> On Wed, May 10, 2023 at 3:23 PM Drouvot, Bertrand
> wrote:
> >
> > >> My current guess is that mis-using a condition variable is the best
> > >> bet. I think it should work to use
> > >> ConditionVariablePrepareToSleep() before a WalS
On Wed, May 10, 2023 at 3:23 PM Drouvot, Bertrand
wrote:
>
> >> My current guess is that mis-using a condition variable is the best bet. I
> >> think it should work to use ConditionVariablePrepareToSleep() before a
> >> WalSndWait(), and then ConditionVariableCancelSleep(). I.e. to never use
> >>
On Wednesday, May 10, 2023 3:03 AM Andres Freund wrote:
> Hi,
>
> Unfortunately I have found the following commit to have caused a
> performance
> regression:
>
> commit e101dfac3a53c20bfbf1ca85d30a368c2954facf
> Author: Andres Freund
> Date: 2023-04-08 00:24:24 -0700
>
> For cascading r
On Wed, May 10, 2023 at 7:33 PM Amit Kapila wrote:
>
> On Wed, May 10, 2023 at 3:41 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Wednesday, May 10, 2023 2:36 PM Bharath Rupireddy
> > wrote:
> > >
> > >
> > > > My current guess is that mis-using a condition variable is the best
> > > > bet. I
>
On Wed, May 10, 2023 at 3:41 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Wednesday, May 10, 2023 2:36 PM Bharath Rupireddy
> wrote:
> >
> >
> > > My current guess is that mis-using a condition variable is the best bet. I
> > > think it should work to use ConditionVariablePrepareToSleep() before a
> >
On Wednesday, May 10, 2023 2:36 PM Bharath Rupireddy
wrote:
>
> On Wed, May 10, 2023 at 12:33 AM Andres Freund
> wrote:
> >
> > Unfortunately I have found the following commit to have caused a
> performance
> > regression:
> >
> > commit e101dfac3a53c20bfbf1ca85d30a368c2954facf
> >
> > The pro
Hi,
On 5/10/23 8:36 AM, Bharath Rupireddy wrote:
On Wed, May 10, 2023 at 12:33 AM Andres Freund wrote:
Unfortunately I have found the following commit to have caused a performance
regression:
commit e101dfac3a53c20bfbf1ca85d30a368c2954facf
The problem is that, on a standby, after the change
Hi,
On 5/9/23 11:00 PM, Andres Freund wrote:
Hi,
On 2023-05-09 13:38:24 -0700, Jeff Davis wrote:
On Tue, 2023-05-09 at 12:02 -0700, Andres Freund wrote:
I don't think the approach of not having any sort of "registry" of
whether
anybody is waiting for the replay position to be updated is
feasi
On Wed, May 10, 2023 at 12:33 AM Andres Freund wrote:
>
> Unfortunately I have found the following commit to have caused a performance
> regression:
>
> commit e101dfac3a53c20bfbf1ca85d30a368c2954facf
>
> The problem is that, on a standby, after the change - as needed to for the
> approach to work
Hi,
On 2023-05-09 13:38:24 -0700, Jeff Davis wrote:
> On Tue, 2023-05-09 at 12:02 -0700, Andres Freund wrote:
> > I don't think the approach of not having any sort of "registry" of
> > whether
> > anybody is waiting for the replay position to be updated is
> > feasible. Iterating over all walsende
On Tue, 2023-05-09 at 12:02 -0700, Andres Freund wrote:
> I don't think the approach of not having any sort of "registry" of
> whether
> anybody is waiting for the replay position to be updated is
> feasible. Iterating over all walsenders slots is just too expensive -
Would it work to use a shared
30 matches
Mail list logo
