Re: Excessive WAL generation and related performance issue - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Excessive WAL generation and related performance issue
Date
Msg-id 20140415004007.GY2556@tamriel.snowman.net
Whole thread Raw
In response to Re: Excessive WAL generation and related performance issue  (Joe Conway <mail@joeconway.com>)
Responses Re: Excessive WAL generation and related performance issue  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
* Joe Conway (mail@joeconway.com) wrote:
> That's the thing. I'm sure there is tuning and other things to improve
> this particular case, but creating over 20 times as much WAL as real
> data seems like pathological behavior to me.

Setting things up such that you are updating a single value on each page
in an index during each checkpoint, which then requires basically
rewriting the entire index as full page writes at checkpoint time, is
definitely pathological behavior- but sadly, not behavior we are likely
to be able to fix..

This sounds like a great example of the unlogged table -> logged table
use-case and makes me wonder if we could provide an optimization similar
to the existing CREATE TABLE + COPY under wal_level = minimal case,
where we wouldn't WAL log anything for CREATE TABLE + COPY even when
wal_level is above minimal, until COMMIT, at which point we'll blast the
whole thing out in one shot.

Another option that you might consider is ordering your input, if
possible, to improve the chances that the same page is changed multiple
times inside a given checkpoint, hopefully reducing the number of pages
changed.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Clock sweep not caching enough B-Tree leaf pages?
Next
From: Stephen Frost
Date:
Subject: Re: Clock sweep not caching enough B-Tree leaf pages?