| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
tables)
- dumb LZO-style compression (license problems, needs parallel
decompressor, random access penalty, hard to implement too)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-10-27 19:56:19 | Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why? |
| Previous Message | Jesper Krogh | 2010-10-27 19:47:23 | Re: Postgres insert performance and storage requirement compared to Oracle |