| From: | Rod Taylor <pg(at)rbt(dot)ca> |
|---|---|
| To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Quick-and-dirty compression for WAL backup blocks |
| Date: | 2005-06-09 17:37:39 |
| Message-ID: | 1118338659.725.69.camel@home |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > I'd say that's an improvement worth having, especially considering that
> > it requires no net expenditure of CPU time. But the table is certainly
> > still open to discuss more complicated approaches.
>
> If it's not hard to hack in as a test, it'd be interesting to see what
> additional gains a more aggresive compression algorithm like LZW got.
> CPU is more of a concern in that case, but for databases generating a
> lot of WAL it might still be a win.
I've generate a fair amount of WAL segments (about 20GB per day), and
have a CPU issue.
I implemented a cronjob which compresses them using gzip on a different
machine.
Any chance we could have an official compression tool which is
independent of the server itself so we can distribute the load a little?
> BTW, is this the thread you reffered to? I wasn't able to find it in the
> TODO and had to go into the archives to find it...
> http://archives.postgresql.org/pgsql-performance/2005-04/msg00264.php
--
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2005-06-09 18:00:03 | Re: [HACKERS] Added schema selection to pg_restore |
| Previous Message | Marc G. Fournier | 2005-06-09 17:28:46 | Re: The Contrib Roundup (long) |