Arno Brinkman wrote:
his :-( ).

>
> Shot in the dark:
> Also is there a way to switch priority for running requests?
> For requests that already run for a long time (what is long?) it
> often doesn't care if it will take
> somewhat seconds longer. With other words: give a starting
> statement a "middle priority", but when
> running longer than X (fetches/ticks/looper visits/or whatever)
> is should not take too much IO/CPU
> away for newly starting statements and therefor falls down to "lower
> priority".

Let's assume you start a race with a turtle to see who comes first to the
same place: your common home. However, the house's keys are hanging from the
turtle's neck. You will get first probably, but will have to wait for the
turtle to reach home be able to open the door with the keys or will have to
go back and get the keys or go back and piggyback the turtle.

When a high priority process is waiting for a low prority process to release
a resource, you risk a deadlock. You'll wait for something you aren't
allowing to run.

I see people proposing fetches and several variations of time to stop the
query. The problem with time is that despite an accurate clock, time will be
subjective to users. The problem with fetches is that given a sort, all
records have to be internally retrieved and sorted before the first fetch
happens, then why not define reads? The problem with reads is that they're
more abstract for the user. Pages read, records reads, do we count record
versions needed to reconstruct the record, etc. Also, I see people worry
about SELECT statements almost exclusively. Should an UPDATE be stopped,
too?

Given that we have too many issues to discuss with those "quotas", it seem a
sensible compromise for FB2 to implement a way to identify and kill a query.
In the worst (simplest) case, let the user cancel its own query. Tokens are
only created if requested.

A half baked solution would be an API that simply kills all requests
associated with the client's address, but this is not going to work with NAT
or local connections or worse, with web clients.

C.