On Fri, 2009-01-02 at 19:27 -0700, Alex Hunsaker wrote: > On Fri, Jan 2, 2009 at 18:30, Tom Lane <t...@sss.pgh.pa.us> wrote: > > "Alex Hunsaker" <bada...@gmail.com> writes: > >> On Fri, Jan 2, 2009 at 11:44, Tom Lane <t...@sss.pgh.pa.us> wrote: > >>> An easy way to prove or disprove the point would be to go into > >>> src/backend/utils/adt/pg_lzcompress.c, and change the second entry > >>> in strategy_default_data from "1024 * 1024" to "INT_MAX", > > > >> And the toast file size is *drum roll* 167M. > > > > Hmmm ... so that's a lot closer to the original 145M, but it still > > seems like there's something else going on. It looks like the other > > thing we changed that might result in not compressing things was to > > increase the third entry (minimum compression rate) from 20% to 25%. > > Could you try it with that value also changed back? > > With it back to 20% its now back to 145M.
Perspective on this is that the numbers don't sound too bad if we put a big M behind them, but lets imagine that's a G or even a T. Those numbers look pretty sad then. We must retain the option to compress and even better, options to control the compression. Please, please remember that the world genuinely does wish to store multiple Terabytes of data and they won't do it with Postgres unless we act sensibly on this point. Our open source software *enables* massive deployment of database technology. Oracle charge money for their Advanced Compression option, so if lets avoid anything that will immediately justify that cost. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers