On Wed, Oct 27, 2010 at 05:49:42PM -0400, Tom Lane wrote: > Kenneth Marshall <ktm@xxxxxxxx> writes: > > Just keeping the hope alive for faster compression. > > Is there any evidence that that's something we should worry about? > I can't recall ever having seen a code profile that shows the > pg_lzcompress.c code high enough to look like a bottleneck compared > to other query costs. > > Now, the benefits of 2X or 3X space savings would be pretty obvious, > but I've seen no evidence that we could easily achieve that either. > > regards, tom lane > One use is to allow substr() on toasted values without needing to decompress the entire contents. Another possibility is to keep larger fields compressed in memory for some value of "larger". With faster compression, it might by useful to compress the WAL files to support faster data rates and therefore update rates for the same hardware. And there are always the in page common substring storage optimizations to reduce index/table sizes. Regards, Ken -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
