Greg Stark <gsst...@mit.edu> writes:
> On Fri, Mar 25, 2011 at 8:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Interesting, but I don't understand/believe your argument as to why this
>> is a bad idea or fixed-size extents are better. It sounds to me just
>> like the typical Oracle DBA compulsion to have a knob to twiddle. A
>> self-adjusting enlargement behavior seems smarter all round.
> So is it ok for inserting one row to cause my table to grow by 90GB?
If the table is already several TB, why not? The whole point here is
that it's very unlikely that you're not going to be inserting more rows
pretty soon.
> Or should there be some maximum size increment at which it stops
> growing? What should that maximum be? What if I'm on a big raid system
> where that size doesn't even add a block to every stripe element?
> Say you start with 64k (8 pg blocks). That means your growth
> increments will be 64k, 70k, 77kl, 85k, 94k, 103k, 113k, 125k, 137k,
> ...
I have no problem with trying to be smart about allocating in powers of
2, not allocating more than X at a time, etc etc. I'm just questioning
the idea that the user should be bothered with this, or is likely to be
smarter than the system about such things. Particularly if you believe
that this problem actually justifies attention to such details. I think
you've already demonstrated that a simplistic fixed-size allocation
parameter probably *isn't* good enough.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
