Thread: Compressing WAL

Compressing WAL

From
"Jim C. Nasby"
Date:
Maybe better for -hackers, but here it goes anyway...

Has anyone looked at compressing WAL's before writing to disk? On a
system generating a lot of WAL it seems there might be some gains to be
had WAL data could be compressed before going to disk, since today's
machines are generally more I/O bound than CPU bound. And unlike the
base tables, you generally don't need to read the WAL, so you don't
really need to worry about not being able to quickly scan through the
data without decompressing it.
--
Jim C. Nasby, Database Consultant               decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Re: Compressing WAL

From
Bruce Momjian
Date:
Jim C. Nasby wrote:
> Maybe better for -hackers, but here it goes anyway...
>
> Has anyone looked at compressing WAL's before writing to disk? On a
> system generating a lot of WAL it seems there might be some gains to be
> had WAL data could be compressed before going to disk, since today's
> machines are generally more I/O bound than CPU bound. And unlike the
> base tables, you generally don't need to read the WAL, so you don't
> really need to worry about not being able to quickly scan through the
> data without decompressing it.

I have never heard anyone talk about it, but it seems useful.  I think
compressing the page images written on first page modification since
checkpoint would be a big win.

Is this a TODO?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: Compressing WAL

From
"Qingqing Zhou"
Date:
""Jim C. Nasby"" <decibel@decibel.org> writes
> Has anyone looked at compressing WAL's before writing to disk? On a
> system generating a lot of WAL it seems there might be some gains to be
> had WAL data could be compressed before going to disk, since today's
> machines are generally more I/O bound than CPU bound. And unlike the
> base tables, you generally don't need to read the WAL, so you don't
> really need to worry about not being able to quickly scan through the
> data without decompressing it.
> --

The problem is where you put the compression code? If you put it inside
XLogInsert lock or XLogWrite lock, which will hold the lock too long? Or
anywhere else?

Regards,
Qingqing




Re: Compressing WAL

From
"Jim C. Nasby"
Date:
On Sun, Apr 10, 2005 at 09:12:41PM -0400, Bruce Momjian wrote:
> I have never heard anyone talk about it, but it seems useful.  I think
> compressing the page images written on first page modification since
> checkpoint would be a big win.

Could you clarify that? Maybe I'm being naive, but it seems like you
could just put a compression routine between the log writer and the
filesystem.

> Is this a TODO?

ISTM it's at least worth hacking something together and doing some
performance testing...
--
Jim C. Nasby, Database Consultant               decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Re: Compressing WAL

From
Simon Riggs
Date:
On Sun, 2005-04-10 at 21:12 -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > Maybe better for -hackers, but here it goes anyway...
> >
> > Has anyone looked at compressing WAL's before writing to disk? On a
> > system generating a lot of WAL it seems there might be some gains to be
> > had WAL data could be compressed before going to disk, since today's
> > machines are generally more I/O bound than CPU bound. And unlike the
> > base tables, you generally don't need to read the WAL, so you don't
> > really need to worry about not being able to quickly scan through the
> > data without decompressing it.
>
> I have never heard anyone talk about it, but it seems useful.  I think
> compressing the page images written on first page modification since
> checkpoint would be a big win.

Well it was discussed 2-3 years ago as part of the PITR preamble. You
may be surprised to read that over...

A summary of thoughts to date on this are:

xlog.c XLogInsert places backup blocks into the wal buffers before
insertion, so is the right place to do this. It would be possible to do
this before any LWlocks are taken, so would not not necessarily impair
scalability.

Currently XLogInsert is a severe CPU bottleneck around the CRC
calculation, as identified recently by Tom. Digging further, the code
used seems to cause processor stalls on Intel CPUs, possibly responsible
for much of the CPU time. Discussions to move to a 32-bit CRC would also
be effected by this because of the byte-by-byte nature of the algorithm,
whatever the length of the generating polynomial. PostgreSQL's CRC
algorithm is the fastest BSD code available. Until improvement is made
there, I would not investigate compression further. Some input from
hardware tuning specialists is required...

The current LZW compression code uses a 4096 byte lookback size, so that
would need to be modified to extend across a whole block. An
alternative, suggested originally by Tom and rediscovered by me because
I just don't read everybody's fine words in history, is to simply take
out the freespace in the middle of every heap block that consists of
zeros.

Any solution in this area must take into account the variability of the
size of freespace in database blocks. Some databases have mostly full
blocks, others vary. There would also be considerable variation in
compressability of blocks, especially since some blocks (e.g. TOAST) are
likely to already be compressed. There'd need to be some testing done to
see exactly the point where the costs of compression produce realisable
benefits.

So any solution must be able to cope with both compressed blocks and
non-compressed blocks. My current thinking is that this could be
achieved by using the spare fourth bit of the BkpBlocks portion of the
XLog structure, so that either all included BkpBlocks are compressed or
none of them are, and hope that allows benefit to shine through. Not
thought about heap/index issues.

It is possible that an XLogWriter process could be used to assist in the
CRC and compression calculations also, an a similar process used to
assist decompression for recovery, in time.

I regret I do not currently have time to pursue further.

Best Regards, Simon Riggs


Re: Compressing WAL

From
Bruce Momjian
Date:
Added to TODO:

    * Compress WAL entries [wal]

I have also added this email to TODO.detail.

---------------------------------------------------------------------------

Simon Riggs wrote:
> On Sun, 2005-04-10 at 21:12 -0400, Bruce Momjian wrote:
> > Jim C. Nasby wrote:
> > > Maybe better for -hackers, but here it goes anyway...
> > >
> > > Has anyone looked at compressing WAL's before writing to disk? On a
> > > system generating a lot of WAL it seems there might be some gains to be
> > > had WAL data could be compressed before going to disk, since today's
> > > machines are generally more I/O bound than CPU bound. And unlike the
> > > base tables, you generally don't need to read the WAL, so you don't
> > > really need to worry about not being able to quickly scan through the
> > > data without decompressing it.
> >
> > I have never heard anyone talk about it, but it seems useful.  I think
> > compressing the page images written on first page modification since
> > checkpoint would be a big win.
>
> Well it was discussed 2-3 years ago as part of the PITR preamble. You
> may be surprised to read that over...
>
> A summary of thoughts to date on this are:
>
> xlog.c XLogInsert places backup blocks into the wal buffers before
> insertion, so is the right place to do this. It would be possible to do
> this before any LWlocks are taken, so would not not necessarily impair
> scalability.
>
> Currently XLogInsert is a severe CPU bottleneck around the CRC
> calculation, as identified recently by Tom. Digging further, the code
> used seems to cause processor stalls on Intel CPUs, possibly responsible
> for much of the CPU time. Discussions to move to a 32-bit CRC would also
> be effected by this because of the byte-by-byte nature of the algorithm,
> whatever the length of the generating polynomial. PostgreSQL's CRC
> algorithm is the fastest BSD code available. Until improvement is made
> there, I would not investigate compression further. Some input from
> hardware tuning specialists is required...
>
> The current LZW compression code uses a 4096 byte lookback size, so that
> would need to be modified to extend across a whole block. An
> alternative, suggested originally by Tom and rediscovered by me because
> I just don't read everybody's fine words in history, is to simply take
> out the freespace in the middle of every heap block that consists of
> zeros.
>
> Any solution in this area must take into account the variability of the
> size of freespace in database blocks. Some databases have mostly full
> blocks, others vary. There would also be considerable variation in
> compressability of blocks, especially since some blocks (e.g. TOAST) are
> likely to already be compressed. There'd need to be some testing done to
> see exactly the point where the costs of compression produce realisable
> benefits.
>
> So any solution must be able to cope with both compressed blocks and
> non-compressed blocks. My current thinking is that this could be
> achieved by using the spare fourth bit of the BkpBlocks portion of the
> XLog structure, so that either all included BkpBlocks are compressed or
> none of them are, and hope that allows benefit to shine through. Not
> thought about heap/index issues.
>
> It is possible that an XLogWriter process could be used to assist in the
> CRC and compression calculations also, an a similar process used to
> assist decompression for recovery, in time.
>
> I regret I do not currently have time to pursue further.
>
> Best Regards, Simon Riggs
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073