Re: Select count(*), the sequel

From: Kenneth Marshall <ktm(at)rice(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pierre C <lists(at)peufeu(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Select count(*), the sequel
Date: 2010-10-28 13:34:36
Message-ID: 20101028133436.GE27429@aart.is.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jon Nelson 2010-10-28 14:08:06 Re: temporary tables, indexes, and query plans
Previous Message Merlin Moncure 2010-10-28 13:13:22 Re: Postgres insert performance and storage requirement compared to Oracle