> 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,
Not that pg_compresslog isn't useful on its own for improving warm standby
managability, but it's completely separate from addressing the "we're logging
too much" issue.
PostgreSQL @ Sun
In response to
pgsql-hackers by date
|Next:||From: Steve Crawford||Date: 2007-04-25 18:51:28|
|Subject: Re: Vacuum-full very slow|
|Previous:||From: Richard Huxton||Date: 2007-04-25 18:05:32|
|Subject: Re: Schema as versioning strategy|
pgsql-patches by date
|Next:||From: Magnus Hagander||Date: 2007-04-25 18:59:02|
|Subject: Re: Fix for MSVC header installation|
|Previous:||From: sangeetha k.s||Date: 2007-04-25 16:23:25|
|Subject: bitmap index implementation|