From: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: increasing the default WAL segment size |
Date: | 2016-08-25 22:45:25 |
Message-ID: | 9dd811a2-bf20-e764-9407-8561f2647c25@archidevsys.co.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 26/08/16 05:43, Josh Berkus wrote:
> On 08/25/2016 01:12 PM, Robert Haas wrote:
>>> I agree that #4 is best. I'm not sure it's worth the cost. I'm not worried
>>>> at all about the risk of master/slave sync thing, per previous statement.
>>>> But if it does have performance implications, per Andres suggestion, then
>>>> making it configurable at initdb time probably comes with a cost that's not
>>>> worth paying.
>> At this point it's hard to judge, because we don't have any idea what
>> the cost might be. I guess if we want to pursue this approach,
>> somebody will have to code it up and benchmark it. But what I'm
>> inclined to do for starters is put together a patch to go from 16MB ->
>> 64MB. Committing that early this cycle will give us time to
>> reconsider if that turns out to be painful for reasons we haven't
>> thought of yet. And give tool authors time to make adjustments, if
>> any are needed.
> The one thing I'd be worried about with the increase in size is folks
> using PostgreSQL for very small databases. If your database is only
> 30MB or so in size, the increase in size of the WAL will be pretty
> significant (+144MB for the base 3 WAL segments). I'm not sure this is
> a real problem which users will notice (in today's scales, 144MB ain't
> much), but if it turns out to be, it would be nice to have a way to
> switch it back *just for them* without recompiling.
>
Let such folk use Microsoft Access??? <Ducks & runs away very fast!>
More seriously:
Surely most such people would be using very old hardware & not likely to
be upgrading to the most recent version of pg in the near future? And
for the ones using modern hardware: either they have enough resources
not to notice, or very probably will know enough to hunt round for a way
to reduce the WAL size - I strongly suspect.
Currently, I'm not support pg in any production environment, and using
it for testing & keeping up-to-date with pg. So it would affect me -
however, I have enough resources so it is no problem in practice.
Cheers,
Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | neha khatri | 2016-08-25 23:29:04 | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Previous Message | Alvaro Herrera | 2016-08-25 21:51:45 | Re: [COMMITTERS] pgsql: Add the "snapshot too old" feature |