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 <br...@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 +
