Re: tackling full page writes

Robert Haas wrote:
> That idea has the additional advantage of confusing the level of
> detail of our WAL logging (minimal vs. archive vs. hot standby) with
> the mechanism used to protect against torn pages (full page writes vs.
> idempotent WAL records vs. prayer). When they set it wrong and
> destroy their system, we can tell them it's their own fault for not
> configuring the system properly! Bwahahahaha!

I love it! Create confusing configuration options and blame the user!

> In all seriousness, I can't imagine that we'd make this
> user-configurable in the first place, since that would amount to
> having two sets of WAL records each of which would be even less well
> tested than what we have now; and for a project this complex, we
> probably shouldn't even consider changing things that seem to work now
> unless the new system is clearly better than the old.
>
> > Idempotent does seem like the most promising idea.
>
> I tend to agree with you, but I'm worried it won't actually work out
> to a win. By the time we augment the records with enough additional
> information we may have eaten up a lot of the benefit we were hoping
> to get.

This is where I was confused. Our bad case now is when someone modifies
one row on a page between checkpoints --- instead of writing 400 bytes,
we write 8400. What portion of between-checkpoint activity writes more
than a few rows to a page? I didn't think many, except for COPY.
Ideally we could switch in and out of this mode per page, but that seems
super-complicated.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +