From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kenneth Marshall <ktm@rice.edu>
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: Wed, 27 Oct 2010 17:49:42 -0400
Message-ID: <29056.1288216182@sss.pgh.pa.us> (raw)
In-Reply-To: <20101027204115.GB27429@aart.is.rice.edu>
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>
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
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: tgl@sss.pgh.pa.us, ktm@rice.edu, lists@peufeu.com, robertmhaas@gmail.com, mladen.gogala@vmsinfo.com
Subject: Re: Select count(*), the sequel
In-Reply-To: <29056.1288216182@sss.pgh.pa.us>
* 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