On Sat, Jan 3, 2009 at 20:47, Philip Warner <p...@rhyme.com.au> wrote: > Tom Lane wrote: >> It would be fairly easy, I think, to add some reloption fields that >> would let these parameters be controlled on a per-table level. >> Per-column would be much more painful; do we really need that? >> > > Another +1 on the per-table setting. Or a config file setting to disable > this for the instance. > > We have a 200GB DB that is mostly large text (>1MB) that is not searched > with substr. If we see a blowout in size of even 3x, we will not be able > to upgrade due to disk space limitations (at least without paying for a > lot of disks on mirror servers and hot-standy servers).
Well I *really* doubt unless your text is extremely redundant you will see a large increase if any. Even if you dont search by substr, fetching the data is quite could be quite a bit faster. Depending on how beefy the cpu's on the machine are. A quick benchmark here says by as much 200x! (30tps vs 6000tps). Thats just a simple select on a dual 2ghz opteron. For the record I just imported a production database that sits at about ~20G right now with *zero* size increase (rounding to the nearest gigabyte). That's with basically the exact same schema just different data. I don't suppose you could export some random rows and see if you see any size increase for your data? My gut says you wont see an increase. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers