On 01/21/2017 05:53 PM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost <sfr...@snowman.net> writes:
* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
The change of wal_level was supported by benchmark, I think it's
reasonable to ask for this to be as well.
No, it wasn't, it was that people felt the cases where changing
wal_level would seriously hurt performance didn't out-weigh the value of
making the change to the default.
It was "supported" in the sense that somebody took the trouble to
measure the impact, so that we had some facts on which to base the
value judgment that the cost was acceptable. In the case of
checksums, you seem to be in a hurry to arrive at a conclusion
without any supporting evidence.
Exactly.
No, no one measured the impact in the cases where wal_level=minimal
makes a big difference, that I saw, at least.
We already knew we can construct data-loading workloads relying on the
wal_level=minimal optimization and demonstrating pretty arbitrary
benefits, so there was no point in benchmarking them. That does not mean
those cases were not considered, though.
>
Further info with links to what was done are in my reply to Petr.
As for checksums, I do see value in them and I'm pretty sure that
the author of that particular feature did as well, or we wouldn't
even have it as an option. You seem to be of the opinion that we
might as well just rip all of that code and work out as being
useless.
I do see value in them too, and if turning then off again would be as
simple as reverting back to wal_level=minimal, I would be strongly in
favor of enabling then to 'on' by default (after a bit of benchmarking,
similar to what we did in the wal_level=minimal case).
The fact that disabling them requires initdb makes the reasoning much
trickier, though.
That being said, I'm ready to do some benchmarking on this, so that we
have at least some numbers to argue about. Can we agree on a set of
workloads that we want to benchmark in the first round?
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
