Re: Compression of full-page-writes - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Compression of full-page-writes
Date
Msg-id CA+TgmoZgT1_efgiV1WJ1hDcj3n9D0SmO6i7m3oQ+yeO2GtP01w@mail.gmail.com
Whole thread Raw
In response to Re: Compression of full-page-writes  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, Jan 2, 2015 at 11:52 AM, Bruce Momjian <bruce@momjian.us> wrote:
> OK, so given your stats, the feature give a 12.5% reduction in I/O.  If
> that is significant, shouldn't we see a performance improvement?  If we
> don't see a performance improvement, is I/O reduction worthwhile?  Is it
> valuable in that it gives non-database applications more I/O to use?  Is
> that all?
>
> I suggest we at least document that this feature as mostly useful for
> I/O reduction, and maybe say CPU usage and performance might be
> negatively impacted.
>
> OK, here is the email I remember from Fujii Masao this same thread that
> showed a performance improvement for WAL compression:
>
>         http://www.postgresql.org/message-id/CAHGQGwGqG8e9YN0fNCUZqTTT=hNr7Ly516kfT5ffqf4pp1qnHg@mail.gmail.com
>
> Why are we not seeing the 33% compression and 15% performance
> improvement he saw?  What am I missing here?

Bruce, some database workloads are I/O bound and others are CPU bound.
Any patch that reduces I/O by using CPU is going to be a win when the
system is I/O bound and a loss when it is CPU bound.  I'm not really
sure what else to say about that; it seems pretty obvious.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs
Next
From: Glyn Astill
Date:
Subject: Re: Merging postgresql.conf and postgresql.auto.conf