Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 7AD941336FA7 for ; Wed, 27 Oct 2010 16:53:01 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 80090-04 for ; Wed, 27 Oct 2010 19:52:54 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213]) by mail.postgresql.org (Postfix) with SMTP id A7CDA1337B5C for ; Wed, 27 Oct 2010 16:52:53 -0300 (ADT) Received: (qmail 32552 invoked by uid 503); 27 Oct 2010 19:32:06 -0000 Received: from b6.ovh.net (HELO mail423.ha.ovh.net) (213.186.33.56) by 30.mail-out.ovh.net with SMTP; 27 Oct 2010 19:32:06 -0000 Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 27 Oct 2010 21:52:50 +0200 Received: from par69-8-88-161-102-87.fbx.proxad.net (HELO apollo13) (lists%peufeu.com@88.161.102.87) by ns0.ovh.net with SMTP; 27 Oct 2010 21:52:50 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Haas" , "Tom Lane" Cc: "Kenneth Marshall" , "Mladen Gogala" , pgsql-performance@postgresql.org Subject: Re: Select count(*), the sequel References: <4CB9D89E.7050701@vmsinfo.com> <20101016184443.GA4993@aart.is.rice.edu> <2091.1288133491@sss.pgh.pa.us> Date: Wed, 27 Oct 2010 21:52:49 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Pierre C" Message-ID: In-Reply-To: <2091.1288133491@sss.pgh.pa.us> User-Agent: Opera Mail/10.62 (Linux) X-Ovh-Tracer-Id: 9444329894445647504 X-Ovh-Remote: 88.161.102.87 (par69-8-88-161-102-87.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.5/N X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201010/507 X-Sequence-Number: 40925 > Even if somebody had a > great idea that would make things smaller without any other penalty, > which I'm not sure I believe either. I'd say that the only things likely to bring an improvement significant enough to warrant the (quite large) hassle of implementation would be : - read-only / archive tables (get rid of row header overhead) - in-page compression using per-column delta storage for instance (no random access penalty, but hard to implement, maybe easier for read-only tables) - dumb LZO-style compression (license problems, needs parallel decompressor, random access penalty, hard to implement too)