On Wed, Oct 27, 2010 at 05:49:42PM -0400, Tom Lane wrote:
> Kenneth Marshall <ktm@rice.edu> 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
