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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
