db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: DERBY-31: setQueryTimeout semantics
Date Fri, 22 Apr 2005 17:08:39 GMT
RPost wrote:

>>"Daniel John Debrunner" wrote:
>>One of the ways to make an easy
>>to use database is to start with the mindset that no tuning properties
>>should be allowed and work from that.
> Or perhaps to start with the mindset that no tuning properties
> should be 'required'. As long as they are not required I have no problem
> with having properties that can be set by the user.
>>I believe that Derby already has too many tuning properties and would
>>like to see it move towards a single tuning property, such "how much
>>memory can this database use". Everything else would be self tuned.
> Would you have the same concern if the existing tuning properties were
> 'self tuning'? Maybe the focus should be more on making the existing
> properties tune themselves rather than eliminating them altogether.

Maybe not.

I just see the common approach is just to add the tuning parameter and
make the application developer/customer figure out how to set it. What's
usually worse is that such properties are added by skiled database
internal engineers and thus can only be understood by skilled database
engineers, usually specific to that database. For an easy to use
database the tuning properties should be in terms anyone can understand,
such as total memory use, not number of buffer pages.


View raw message