Hi,
On 2020-06-09 08:52:24 +0200, Peter Eisentraut wrote:
> On 2020-06-08 23:32, Andres Freund wrote:
> > On 2020-06-08 13:27:50 -0400, Tom Lane wrote:
> > > If we can allow wal_level to be changed on the fly, I agree that would
> > > help reduce the pressure to make the default setting more expen
On Tue, Jun 9, 2020 at 6:57 PM Amit Kapila wrote:
>
> On Tue, Jun 9, 2020 at 3:02 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2020-06-08 13:27:50 -0400, Tom Lane wrote:
> > > If we can allow wal_level to be changed on the fly, I agree that would
> > > help reduce the pressure to make the defau
On Tue, Jun 9, 2020 at 3:02 AM Andres Freund wrote:
>
> Hi,
>
> On 2020-06-08 13:27:50 -0400, Tom Lane wrote:
> > If we can allow wal_level to be changed on the fly, I agree that would
> > help reduce the pressure to make the default setting more expensive.
> > I don't recall why it's PGC_POSTMAST
On Tue, Jun 9, 2020 at 4:58 PM Magnus Hagander wrote:
>
> On Tue, Jun 9, 2020 at 1:20 PM Amit Kapila wrote:
>>
>> On Tue, Jun 9, 2020 at 2:31 PM Magnus Hagander wrote:
>> >
>> > On Tue, Jun 9, 2020 at 10:53 AM Kyotaro Horiguchi
>> > wrote:
>> >>
>> >> At Tue, 9 Jun 2020 08:52:24 +0200, Peter E
On Tue, Jun 9, 2020 at 1:20 PM Amit Kapila wrote:
> On Tue, Jun 9, 2020 at 2:31 PM Magnus Hagander
> wrote:
> >
> > On Tue, Jun 9, 2020 at 10:53 AM Kyotaro Horiguchi <
> horikyota@gmail.com> wrote:
> >>
> >> At Tue, 9 Jun 2020 08:52:24 +0200, Peter Eisentraut <
> peter.eisentr...@2ndquadrant
On Tue, Jun 9, 2020 at 2:31 PM Magnus Hagander wrote:
>
> On Tue, Jun 9, 2020 at 10:53 AM Kyotaro Horiguchi
> wrote:
>>
>> At Tue, 9 Jun 2020 08:52:24 +0200, Peter Eisentraut
>> wrote in
>> > On 2020-06-08 23:32, Andres Freund wrote:
>> > > On 2020-06-08 13:27:50 -0400, Tom Lane wrote:
>> > >>
On Tue, Jun 9, 2020 at 10:53 AM Kyotaro Horiguchi
wrote:
> At Tue, 9 Jun 2020 08:52:24 +0200, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote in
> > On 2020-06-08 23:32, Andres Freund wrote:
> > > On 2020-06-08 13:27:50 -0400, Tom Lane wrote:
> > >> If we can allow wal_level to be ch
At Tue, 9 Jun 2020 08:52:24 +0200, Peter Eisentraut
wrote in
> On 2020-06-08 23:32, Andres Freund wrote:
> > On 2020-06-08 13:27:50 -0400, Tom Lane wrote:
> >> If we can allow wal_level to be changed on the fly, I agree that would
> >> help reduce the pressure to make the default setting more ex
On 2020-06-08 23:32, Andres Freund wrote:
On 2020-06-08 13:27:50 -0400, Tom Lane wrote:
If we can allow wal_level to be changed on the fly, I agree that would
help reduce the pressure to make the default setting more expensive.
I don't recall why it's PGC_POSTMASTER right now, but I suppose ther
Hi,
On 2020-06-08 13:27:50 -0400, Tom Lane wrote:
> If we can allow wal_level to be changed on the fly, I agree that would
> help reduce the pressure to make the default setting more expensive.
> I don't recall why it's PGC_POSTMASTER right now, but I suppose there
> was a reason for that ...
The
Hi,
On 2020-06-08 14:58:03 -0400, Robert Haas wrote:
> On Mon, Jun 8, 2020 at 1:16 PM Alvaro Herrera
> wrote:
> > I think it's reasonable to push our default limits for slots,
> > walsenders, max_bgworkers etc a lot higher than current value (say 10 ->
> > 100). An unused slot wastes essentiall
On Mon, Jun 8, 2020 at 12:28 PM Alvaro Herrera wrote:
> On a quantum-mechanics level, sure, but after Andres's snapshot
> scalability patches, will it be measurable? (Besides, if your workload
> is so high that you're measurably affected by the additional unused
> PGPROC entries, you can always t
On 2020-Jun-08, Robert Haas wrote:
> On Mon, Jun 8, 2020 at 1:16 PM Alvaro Herrera
> wrote:
> > I think it's reasonable to push our default limits for slots,
> > walsenders, max_bgworkers etc a lot higher than current value (say 10 ->
> > 100). An unused slot wastes essentially no resources; an
On Mon, Jun 8, 2020 at 12:09 PM Robert Haas wrote:
> I think the big overhead is that you log the old version of each row's
> primary key (or whatever the replica identity is) when performing an
> UPDATE or DELETE. So if you test it with integer keys probably it's
> not bad, and I suspect (though
On Mon, Jun 8, 2020 at 5:11 AM Magnus Hagander wrote:
> I agree that we should consider changing it *if* it does not come with a
> substantial overhead, but that has to be shown.
I think the big overhead is that you log the old version of each row's
primary key (or whatever the replica identity
On Mon, Jun 08, 2020 at 02:58:03PM -0400, Robert Haas wrote:
> On Mon, Jun 8, 2020 at 1:16 PM Alvaro Herrera
> wrote:
> > I think it's reasonable to push our default limits for slots,
> > walsenders, max_bgworkers etc a lot higher than current value (say 10 ->
> > 100). An unused slot wastes ess
On Mon, Jun 8, 2020 at 1:16 PM Alvaro Herrera wrote:
> I think it's reasonable to push our default limits for slots,
> walsenders, max_bgworkers etc a lot higher than current value (say 10 ->
> 100). An unused slot wastes essentially no resources; an unused
> walsender is just one PGPROC entry.
Alvaro Herrera writes:
> I think it's reasonable to push our default limits for slots,
> walsenders, max_bgworkers etc a lot higher than current value (say 10 ->
> 100). An unused slot wastes essentially no resources; an unused
> walsender is just one PGPROC entry. If we did that, and also allow
On 2020-Jun-08, Tomas Vondra wrote:
> Not sure if it's sufficient, though, because switching to logical may
> require bumping up number of slots, walsenders, etc. At which point you
> actually need a restart. Not to mention that extensions using logical
> decoding (like pglogical) need to allocate
On Mon, Jun 08, 2020 at 11:10:38AM +0200, Magnus Hagander wrote:
> On Mon, Jun 8, 2020 at 8:46 AM Michael Paquier wrote:
>
> > On Mon, Jun 08, 2020 at 11:59:14AM +0530, Amit Kapila wrote:
> > > I think we should first do performance testing to see what is the
> > > overhead of making this default
On Mon, Jun 08, 2020 at 11:10:38AM +0200, Magnus Hagander wrote:
On Mon, Jun 8, 2020 at 8:46 AM Michael Paquier wrote:
On Mon, Jun 08, 2020 at 11:59:14AM +0530, Amit Kapila wrote:
> I think we should first do performance testing to see what is the
> overhead of making this default. I think pg
On Mon, Jun 8, 2020 at 8:46 AM Michael Paquier wrote:
> On Mon, Jun 08, 2020 at 11:59:14AM +0530, Amit Kapila wrote:
> > I think we should first do performance testing to see what is the
> > overhead of making this default. I think pgbench read-write at
> > various scale factors would be a good
On Mon, Jun 08, 2020 at 11:59:14AM +0530, Amit Kapila wrote:
> I think we should first do performance testing to see what is the
> overhead of making this default. I think pgbench read-write at
> various scale factors would be a good starting point. Also, we should
> see how much additional WAL i
On Mon, Jun 8, 2020 at 10:08 AM David Fetter wrote:
>
> Hi,
>
> I'd like to propose $subject, as embodied in the attached patch. This
> makes it possible to discover and fulfill a need for logical
> replication that can arise at a time when bouncing the server has
> become impractical, i.e. when t
24 matches
Mail list logo
