Re: [HACKERS] Checksums by default?
От | Tomas Vondra |
---|---|
Тема | Re: [HACKERS] Checksums by default? |
Дата | |
Msg-id | d1db0e65-ce66-864c-1fe0-c812c5bc8694@2ndquadrant.com обсуждение исходный текст |
Ответ на | [HACKERS] Checksums by default? (Magnus Hagander <magnus@hagander.net>) |
Список | pgsql-hackers |
On 01/21/2017 05:51 PM, Stephen Frost wrote: > * Petr Jelinek (petr.jelinek@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-eb406dbe026f@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
В списке pgsql-hackers по дате отправления: