On Mon, Apr 1, 2019 at 10:16:47AM +0200, Christoph Berg wrote:
> Re: Tomas Vondra 2019-03-30 <20190330192543.GH4719@development>
> > I have not investigated the exact reasons, but my hypothesis it's about
> > the amount of WAL generated during the initial CREATE INDEX (because it
> > probably ends up setting the hint bits), which puts additional pressure
> > on the storage.
> >
> > Unfortunately, this additional cost is unlikely to go away :-(
>
> If WAL volume is a problem, would wal_compression help?
>
> > Now, maybe we want to enable checksums by default anyway, but we should
> > not pretent the only cost related to checksums is CPU usage.
>
> Thanks for doing these tests. The point I'm trying to make is, why do
> we run without data checksums by default? For example, we do checksum
> the WAL all the time, and there's not even an option to disable it,
> even if that might make things faster. Why don't we enable data
> checksums by default as well?
We checksum wal because we know partial WAL writes are likely to happen
during power failure during a write. Data pages have pre-images (GUC
full_page_writes) stored in WAL so they are protected from partial
writes, hence are less likely to need checksum protection to detect
corruption.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +