Jim,

> Leyne, Sean wrote:
>
> >This means that the real need is for elapsed time, not number of
> >reads/fetches, not CPU time.
> >
> The state purpose of the request was to catch "bad" requests, not

relief

> from bored users. Maybe we're talking about one thing here, maybe

two.

I believe we are talking about the same thing.

By mentioning users, I did not immediately mean that they are/were
bored.

I was referring to the need to be able to assure my users (actually
their boses) that the database will not allow for a request to 'runaway'
and consume server resources without end.

> As mentioned, the problem with bored users killing long requests is

that

> they invariably restart them, wasting all of the resources expended so
> far.

I agree!

> ...isn't the better solution a SQL analog of the isc_unwind_request

call?

Yes.


But I believe you will agree, the ability to cancel a query and a
feature which allows for the SYSDBA / Application developer to control
the runtime of a query are not mutually exclusive.

They are complimentary.



Sean