On 01/21/2017 05:51 PM, Stephen Frost wrote:
* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
On 21/01/17 17:31, Stephen Frost wrote:
This is just changing the *default*, not requiring checksums to always
be enabled. We do not hold the same standards for our defaults as we do
for always-enabled code, for clear reasons- not every situation is the
same and that's why we have defaults that people can change.
I can buy that. If it's possible to turn checksums off without
recreating data directory then I think it would be okay to have default on.
I'm glad to hear that.
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.
Really?
Yes.
https://www.postgresql.org/message-id/d34ce5b5-131f-66ce-f7c5-eb406dbe0...@2ndquadrant.com
From the above link:
So while it'd be trivial to construct workloads demonstrating the
optimizations in wal_level=minimal (e.g. initial loads doing
CREATE TABLE + COPY + CREATE INDEX in a single transaction), but
that would be mostly irrelevant I guess.
Instead, I've decided to run regular pgbench TPC-B-like workload on
a bunch of different scales, and measure throughput + some xlog
stats with each of the three wal_level options.
In other words, there was no performance testing of the cases where
wal_level=minimal (the old default) optimizations would have been
compared against wal_level > minimal.
I'm quite sure that the performance numbers for the CREATE TABLE +
COPY case with wal_level=minimal would have been *far* better than
for wal_level > minimal.
That case was entirely punted on as "mostly irrelevant" even though
there are known production environments where those optimizations
make a huge difference. Those are OLAP cases though, and not nearly
enough folks around here seem to care one bit about them, which I
continue to be disappointed by.
You make it look as if we swept that case under the carpet, despite
there being quite a bit of relevant discussion in that thread.
We might argue how many deployments benefit from the Wal_level=minimal
optimization (I'm sure some of our customers do benefit from it too),
and whether it makes it 'common workload' or not.
It's trivial to construct a workload demonstrating pretty arbitrary
performance advantage of the wal_level=minimal case. Hence no point in
wasting time on demonstrating it, making the case rather irrelevant for
the benchmarking.
Moreover, there are quite a few differences between enabling checksums
by default, and switching to wal_level=minimal:
- There are reasonable workaround that give you wal_level=minimal back
(UNLOGGED tables). And those work even when you actually need a standby,
which is pretty common these days. With checksums there's nothing like that.
- You can switch between wal_level values by merely restarting the
cluster, while checksums may only be enabled/disabled by initdb.
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
