From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Koichi Suzuki" <suzuki(dot)koichi(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [PATCHES] Full page writes improvement, code update |
Date: | 2007-03-29 18:45:27 |
Message-ID: | 200703291145.28574.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Simon,
> OK, different question:
> Why would anyone ever set full_page_compress = off?
The only reason I can see is if compression costs us CPU but gains RAM &
I/O. I can think of a lot of applications ... benchmarks included ...
which are CPU-bound but not RAM or I/O bound. For those applications,
compression is a bad tradeoff.
If, however, CPU used for compression is made up elsewhere through smaller
file processing, then I'd agree that we don't need a switch.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2007-03-29 18:54:05 | Re: Server-side support of all encodings |
Previous Message | Tom Lane | 2007-03-29 18:19:38 | Re: Fixing insecure security definer functions |
From | Date | Subject | |
---|---|---|---|
Next Message | Holger Schurig | 2007-03-29 19:27:19 | Re: [PATCH] add CLUSTER table USING index (take 2) |
Previous Message | Bruce Momjian | 2007-03-29 18:12:39 | Re: tsearch_core patch for inclusion |