Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Full page writes improvement, code update

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
Cc: pgsql-hackers(at)postgresql(dot)org, "Koichi Suzuki" <suzuki(dot)koichi(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Full page writes improvement, code update
Date: 2007-04-25 18:27:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches

> 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.

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.

Josh Berkus
PostgreSQL @ Sun
San Francisco

In response to


pgsql-hackers by date

Next:From: Steve CrawfordDate: 2007-04-25 18:51:28
Subject: Re: Vacuum-full very slow
Previous:From: Richard HuxtonDate: 2007-04-25 18:05:32
Subject: Re: Schema as versioning strategy

pgsql-patches by date

Next:From: Magnus HaganderDate: 2007-04-25 18:59:02
Subject: Re: Fix for MSVC header installation
Previous:From: sangeetha k.sDate: 2007-04-25 16:23:25
Subject: bitmap index implementation

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group