> > Writing to a different area was considered in pg, but there were
more
> > negative issues than positive.
> > So imho pg_compresslog is the correct path forward. The current
> > discussion is only about whether we want a more complex
pg_compresslog
> > and no change to current WAL, or an increased WAL size for a less
> > complex implementation.
> > Both would be able to compress the WAL to the same "archive log"
size.
>
> Huh? As conceived, pg_compresslog does nothing to lower log
> volume for general purposes, just on-disk storage size for
> archiving. It doesn't help us at all with the tremendous
> amount of log we put out for an OLTP server, for example.
Ok, that is not related to the original discussion though.
I have thus changed the subject, and removed [PATCHES].
You cannot directly compare the pg WAL size with other db's since they
write parts to other areas (e.g. physical log in Informix). You would
need to include those writes in a fair comparison.
It is definitely not true, that writing to a different area has only
advantages. The consensus was, that writing the page images to the WAL
has more pro's. We could revisit the pros and cons though.
Other options involve special OS and hardware (we already have that), or
accepting a high risc of needing a
restore after power outage (we don't have that, because we use no
mechanism to detect such a failure).
I am not sure that shrinking per WAL record size (other than the full
page images), e.g. by only logging changed bytes and not whole tuples,
would have a huge impact on OLTP tx/sec, since the limiting factor is
IO's per second and not Mb per second. Recent developments like HOT seem
a lot more promising in this regard since they avoid IO.
Andreas
