On Fri, Apr 19, 2013 at 11:17 AM, Christopher Browne <cbbrowne@gmail.com> wrote:
>
> I would expect the strategy you have in mind to be more useful to apply at
> the filesystem level, so that it's not in Postgres altogether. (Ala
> "Stacker", remember DR-DOS?)
>
> But, to speak arguable heresy, the demerits of this sort of thing are
> described nicely in Another Database's Documentation:
> <http://dev.mysql.com/doc/innodb-plugin/1.0/en/innodb-compression-internals-algorithms.html>
>
> The relevant bit that seems to describe fairly aptly why what you are
> suggesting is unlikely to turn out well:
>
> "Some operating systems implement compression at the file system level.
> Files are typically divided into fixed-size blocks that are compressed into
> variable-size blocks, which easily leads into fragmentation. Every time
> something inside a block is modified, the whole block is recompressed before
> it is written to disk. These properties make this compression technique
> unsuitable for use in an update-intensive database system."
>
> The principle described is as applicable to Postgres as it is to InnoDB, and
> is as applicable to attempting to compress disk blocks from within the
> database as it is to apply it at the filesystem layer.
>
> Postgres *does* make use of data compression, where applicable; see the
> documentation for TOAST:
> <http://www.postgresql.org/docs/9.2/static/storage-toast.html>
...which I turn off in cases where I'm concerned about performance :-D.
merlin