On Sun, Apr 24, 2016 at 5:50 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Apr 21, 2016 at 7:20 PM, Robert Haas
> wrote:
> >> I think we are far too close to beta1 to begin bikeshedding this.
> >> Changing the defaults is not going to be uncontroversial, and it's not
> >> something
Magnus Hagander writes:
> On Thu, Apr 21, 2016 at 7:20 PM, Robert Haas wrote:
>> I think we are far too close to beta1 to begin bikeshedding this.
>> Changing the defaults is not going to be uncontroversial, and it's not
>> something I think we should rush into.
> I think that may be a case of t
On Thu, Apr 21, 2016 at 7:20 PM, Robert Haas wrote:
> On Wed, Apr 20, 2016 at 2:04 PM, Magnus Hagander
> wrote:
> > So what more do we need to just get going with this? Given feature freeze
> > we're perhaps too late to actually build the parameter feature for
> initdb,
> > but we could still ch
On Wed, Apr 20, 2016 at 2:04 PM, Magnus Hagander wrote:
> So what more do we need to just get going with this? Given feature freeze
> we're perhaps too late to actually build the parameter feature for initdb,
> but we could still change the defaults (and then we could add such a
> parameter for ne
On Sun, Feb 14, 2016 at 9:58 AM, Magnus Hagander
wrote:
>
>
> On Sun, Feb 14, 2016 at 2:00 AM, Robert Haas
> wrote:
>
>> On Sat, Feb 13, 2016 at 11:31 AM, Andres Freund
>> wrote:
>> > On 2016-02-13 11:10:58 -0500, Tom Lane wrote:
>> >> Magnus Hagander writes:
>> >> > The big thing is, IIRC, th
On Sun, Feb 14, 2016 at 2:00 AM, Robert Haas wrote:
> On Sat, Feb 13, 2016 at 11:31 AM, Andres Freund
> wrote:
> > On 2016-02-13 11:10:58 -0500, Tom Lane wrote:
> >> Magnus Hagander writes:
> >> > The big thing is, IIRC, that we turn off the optimizations in
> >> > min_wal_level. *most* people
On Sat, Feb 13, 2016 at 11:31 AM, Andres Freund wrote:
> On 2016-02-13 11:10:58 -0500, Tom Lane wrote:
>> Magnus Hagander writes:
>> > The big thing is, IIRC, that we turn off the optimizations in
>> > min_wal_level. *most* people will see no impact of their regular
>> > application runtime from
On 2016-02-13 11:10:58 -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > The big thing is, IIRC, that we turn off the optimizations in
> > min_wal_level. *most* people will see no impact of their regular
> > application runtime from that, but it might definitely have an effect on
> > data loads
Magnus Hagander writes:
> On Sat, Feb 13, 2016 at 4:52 PM, Tom Lane wrote:
>> It would be easier to sell this if we had some numbers for the amount of
>> overhead it would add for people *not* using the features. I do not think
>> I've ever seen, eg, pgbench results with different wal_level and
On Sat, Feb 13, 2016 at 4:52 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > Yes, these changes will increase some of the default overhead. My
> argument
> > against that is that anybody who actually cares about that overhead is
> > going to be tuning their database *anyway*, so they can just
Magnus Hagander writes:
> Yes, these changes will increase some of the default overhead. My argument
> against that is that anybody who actually cares about that overhead is
> going to be tuning their database *anyway*, so they can just change things
> back to the old defaults.
> So, I suggest th
On Sat, Feb 13, 2016 at 4:16 PM, Andres Freund wrote:
> Hi,
>
> On 2016-02-13 07:13:55 -0800, Joshua D. Drake wrote:
> > I would like to add the idea of having archiving on by default. Not
> everyone
> > uses streaming replication, some people use PITR. The one that I see is
> > archive_command a
Hi,
On 2016-02-13 07:13:55 -0800, Joshua D. Drake wrote:
> I would like to add the idea of having archiving on by default. Not everyone
> uses streaming replication, some people use PITR. The one that I see is
> archive_command and I am not sure how to deal with that.
Since that requires addition
Hello,
I would like to add the idea of having archiving on by default. Not
everyone uses streaming replication, some people use PITR. The one that
I see is archive_command and I am not sure how to deal with that.
Sincerely,
JD
--
Command Prompt, Inc. http://the.postgres.com
On 02/13/2016 05:37 AM, Michael Paquier wrote:
On Sat, Feb 13, 2016 at 10:15 PM, Magnus Hagander wrote:
So, I suggest the following changes to the defaults:
wal_level=hot_standby
max_wal_senders=10
max_replication_slots=10
10 seems a bit high. I would think that max_wal_senders and
max_replica
On Sat, Feb 13, 2016 at 2:39 PM, Andres Freund wrote:
> On 2016-02-13 22:37:33 +0900, Michael Paquier wrote:
> > On Sat, Feb 13, 2016 at 10:15 PM, Magnus Hagander wrote:
> > > So, I suggest the following changes to the defaults:
> > > wal_level=hot_standby
> > > max_wal_senders=10
> > > max_repli
On 2016-02-13 22:37:33 +0900, Michael Paquier wrote:
> On Sat, Feb 13, 2016 at 10:15 PM, Magnus Hagander wrote:
> > So, I suggest the following changes to the defaults:
> > wal_level=hot_standby
> > max_wal_senders=10
> > max_replication_slots=10
+1. I'm inclined to set slots a bit higher than sen
On Sat, Feb 13, 2016 at 10:15 PM, Magnus Hagander wrote:
> So, I suggest the following changes to the defaults:
> wal_level=hot_standby
> max_wal_senders=10
> max_replication_slots=10
10 seems a bit high. I would think that max_wal_senders and
max_replication_slots set at 3 are sufficient enough,
18 matches
Mail list logo
