Skip site navigation (1) Skip section navigation (2)

Re: Select count(*), the sequel

From: "Pierre C" <lists(at)peufeu(dot)com>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Kenneth Marshall" <ktm(at)rice(dot)edu>, "Mladen Gogala" <mladen(dot)gogala(at)vmsinfo(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Select count(*), the sequel
Date: 2010-10-27 19:52:49
Message-ID: op.vk82ubgueorkce@apollo13 (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
> 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  
- dumb LZO-style compression (license problems, needs parallel  
decompressor, random access penalty, hard to implement too)

In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2010-10-27 19:56:19
Subject: Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
Previous:From: Jesper KroghDate: 2010-10-27 19:47:23
Subject: Re: Postgres insert performance and storage requirement compared to Oracle

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group