Re: Performance Improvement by reducing WAL for Update Operation

On Tue, Feb 11, 2014 at 11:37 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Yes, that was my point. I though the compression of full-page images
> was a huge win and that compression was pretty straight-forward, except
> for the compression algorithm. If the compression algorithm issue is
> resolved, can we move move forward with the full-page compression patch?

Discussion of the full-page compression patch properly belongs on that
thread rather than this one. However, based on what we've discovered
so far here, I won't be very surprised if that patch turns out to have
serious problems with CPU consumption. The evidence from this thread
suggests that making even relatively lame attempts at compression is
extremely costly in terms of CPU overhead. Now, the issues with
straight-up compression are somewhat different than for delta
compression and, in particular, it's easier to bail out of straight-up
compression sooner if things aren't working out. But even with all
that, I expect it to be not too difficult to find cases where some
compression is achieved but with a dramatic increase in runtime on
CPU-bound workloads. Which is basically the same problem this patch
has.

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