On Sat, Jan 3, 2009 at 20:47, Philip Warner <pjw@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.