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.


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

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?


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:

Reply via email to