Alexander Klenin wrote:

>Actually, the idea of quotas is important and fruitful one. Most
>advanced DBMS have the possibility to limit not only elapsed time, but
>also CPU time, memory and disk usage, etc.
>IMO this should be done as a cohesive set of features based neither on
>database nor on client configuration, but on user accounts, so any
>query run by a particular database user is automatically terminated
>after exceeding any kind of quota given to this specific user. This
>functionality could be surfaced as a system table
>
>TABLE RDB$QUOTAS
>(
> RDB$USER INTEGER REFERENCES RDB$USERS(..),
> RDB$MAX_ELAPSED_TIME_MSEC INTEGER,
> RDB$MAX_CPU_TIME_MSEC INTEGER,
> ...
>)
>
>
>

Are these quotas per request, per session (attachment), or per day? If
per request, aren't you just encouraging uses to break piggy requests
into two or more small but less efficient requests? If per session,
isn't this an inducement to reattach frequently to subvert the quota?
And how could per day quotes address the original requirement, which was
to catch runaway queries? Is a developer who accidently started a
runaway query forced to reattach or go home and wait for the next day?

What do you mean by elapsed time? Is it total clock time since a request
began, or does it exclude think time when the request is inactive
pending human interaction?

How to do propose to measure CPU time in a multi-threaded environment?
As has been mentioned, pthreads doesn't expose per-thread CPU times.
Does it really make sense to define a quota that we can't enforce?

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376