Re: Pre-allocated free space for row updating (like PCTFREE)

On Mon, Aug 22, 2005 at 10:18:25PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> > ... But I agree with Satoshi; if there are
> > people who will benefit from this option (which doesn't hurt those who
> > choose not to use it), why not put it in?
>
> Because there's no such thing as a free lunch. Every option we support
> costs us in initial implementation time, documentation effort, and
> ongoing maintenance. Plus it confuses users who don't know what to do
> with it. (Note Josh's nearby lobbying to remove some GUC parameters.
> While I opposed him on that particular item, I sympathize with his
> point in general.)
>
> Oracle's approach of "offer every knob you can think of" is not one
> that I care to emulate. We have to strike a balance between flexibility
> and not having a database that's too complex to administer for anyone
> except an expert.

The problem is that unless you're going to put a lot of AI in the
database[1] (something Oracle is now doing...), you're going to end up
limiting yourself. As the PostgreSQL code continues to improve
performance-wise, we're going to run into more and more situations where
the way to get more performance means adding more tunables. Look at the
knobs that have been added for bgwriter and delayed vacuum for example.
These were added because the code had gotten to a point where the
problems they solve had become bigger and bigger bottlenecks. I know
there's hope that eventually these can be turned into simple 1-10 knobs
or something, but I'm doubtful that something that simple will suffice
for all situations.

I do understand the issue of having 100s of knobs, though. I don't think
we should go adding knobs willy-nilly (Josh made the good point that
there's currently no testing to validate the usefullness of this free
space knob, for example). But I also think that the way to control
'knob-bloat' isn't to do everything possible not to add knobs, but to
look at how to limit their exposure to people who don't need to know
about them.

For example, there's less than a half dozen knobs that people always ask
about when people post performance questions: shared_buffers, work_mem,
effective_cache_size, etc. These are knobs that almost every user needs
to know about. Call them 'level 1' knobs. Level 2 might be things like
vacuum_cost_delay, maintenance_work_mem, max_fsm_pages, and
max_connections. And so on. By grouping in this fashion we can limit
exposure to things that most users won't need to mess with, but give
users who have need to change these things the ability to do so.

[1]: I'm all in favor of making things self-tuning wherever possible,
but that's generally a lot more work than just exposing a GUC, so I
suspect it will be some time before we get to that point.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com 512-569-9461