> > >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.

Exactly - I kinda said that as well.

I agree with Sean. Elapsed time is the only thing that users care about.

A per-statement or per-connection defined timeout makes sense.

A per-database configured timeout makes sense as well (think
web-applications).

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com