Re: QuickLZ compression algorithm (Re: Inclusion in the PostgreSQL backend for toasting rows)

"Robert Haas"  writes:

> Regardless of whether we do that or not, no one has offered any
> justification of the arbitrary decision not to compress columns >1MB,

Er, yes, there was discussion before the change, for instance:
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php


And do you have any response to this point?
I think the right value for this setting is going to depend on theenvironment. If the system is starved for cpu cycles then you won't want tocompress large data. If it's starved for i/o bandwidth but has spare cpucycles then you will.

http://archives.postgresql.org/pgsql-hackers/2009-01/msg00074.php


> and at least one person (Peter) has suggested that it is exactly
> backwards.  I think he's right, and this part should be backed out.

Well the original code had a threshold above which we *always* compresed even
if it saved only a single byte.






--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning