"Stephen R. van den Berg" <s...@cuci.nl> writes: > Alex Hunsaker wrote: >>I think we could just add another toast storage type: alter table >>alter column set storage compress; ? It seems overkill to expose >>PGLZ_Strategy knobs per column... > > Three things: > a. Shouldn't it in theory be possible to have a decompression algorithm > which is IO-bound because it decompresses faster than the disk can > supply the data? (On common current hardware).
We don't stream the data from disk through the decompressor. So whether it's i/o bound or not, the time spend decompressing is in addition to the time spent doing the i/o. The only way it wins is if the time saved on i/o due to the smaller data size is greater than the time spent decompressing. I think the right value for this setting is going to depend on the environment. If the system is starved for cpu cycles then you won't want to compress large data. If it's starved for i/o bandwidth but has spare cpu cycles then you will. If that's true then we really have to expose this parameter to users. There won't be a single value that is appropriate for everyone. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
