Re: Select count(*), the sequel - Mailing list pgsql-performance

From Pierre C
Subject Re: Select count(*), the sequel
Date
Msg-id op.vk82ubgueorkce@apollo13
Whole thread Raw
In response to Re: Select count(*), the sequel  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Select count(*), the sequel
Re: Select count(*), the sequel
List 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)

pgsql-performance by date:

Previous
From: Jesper Krogh
Date:
Subject: Re: Postgres insert performance and storage requirement compared to Oracle
Next
From: Tom Lane
Date:
Subject: Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?