From: Kenneth Marshall <ktm@rice.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pierre C <lists@peufeu.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Mladen Gogala <mladen.gogala@vmsinfo.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Select count(*), the sequel
Date: Thu, 28 Oct 2010 08:34:36 -0500
Message-ID: <20101028133436.GE27429@aart.is.rice.edu> (raw)
In-Reply-To: <29056.1288216182@sss.pgh.pa.us>
References: <4CB9D89E.7050701@vmsinfo.com>
<20101016184443.GA4993@aart.is.rice.edu>
<AANLkTik6ifMywZq7C1_MiHLafOQ53_OXreHYQdps3GqP@mail.gmail.com>
<2091.1288133491@sss.pgh.pa.us>
<op.vk82ubgueorkce@apollo13>
<20101027204115.GB27429@aart.is.rice.edu>
<29056.1288216182@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: ktm@rice.edu, tgl@sss.pgh.pa.us, lists@peufeu.com, robertmhaas@gmail.com, mladen.gogala@vmsinfo.com
Subject: Re: Select count(*), the sequel
In-Reply-To: <20101028133436.GE27429@aart.is.rice.edu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox