On Fri, Apr 19, 2013 at 11:17 AM, Christopher Browne <cbbro...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
