Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.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.
I understand what you mean, but I think we have to provide more flexibility
or options for PostgreSQL to be used wider area in the real-world.
In my case, if many updates reduce the system performance and there is no option,
our customer will change their DBMS from PostgreSQL to MySQL or Oracle.
If the DBAs can choose fewer options, the system performance management(monitoring)
cost gets higher, because sometimes simple architecture causes complex
operations (or tricks) in the real applications (like performance v.s. vacuum).
It is also a part of user's TCO.
I know there is no free lunch.
However, it also means if we can pay more costs, we can get more great lunch.
Just my thought...
--
NAGAYASU Satoshi <nagayasus@nttdata.co.jp>