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,
I know we've had many discussions about the defaults, so hey, let's bring
out the paint-cans and do the bikeshed all over again.
I would suggest a couple of changes to the default values in parameters
related to backup and replication.
The reason for this is to make it "easier to do the right thi
19 matches
Mail list logo
