Subject | Re: Which way is best... |
---|---|
Author | Adam |
Post date | 2005-11-11T22:21:42Z |
--- In firebird-support@yahoogroups.com, Kjell Rilbe
<kjell.rilbe@a...> wrote:
There was a similar discussion a few weeks back when someone (Ali?)
wanted to run some process in a lower priority and all these sorts of
ideas were floated.
Process Priority is CPU based. If the particular slow process is CPU
bound then perhaps it would help, but a batch of inserts is likely to
be mostly I/O bound.
One thing Firebird lacks is a customisable scheduling mechanism to
throttle back any query (maybe like a "nice" directive inside a query,
transaction or connection). I am sure it will come one day, but there
is no reliable way at the moment to ensure "batch processes" dont
interfere with "transactional processes".
The best thing to do currently is to throttle it from the client end,
insert 20 records then delay for a second etc. Of course using
paramatised queries or a stored procedure saves Firebird from having
to prepare the query for each execution, and particular useful indices
will get cached pretty quicky, so it is not all bad news.
Adam
<kjell.rilbe@a...> wrote:
>you
> If classic server, your batch would run on a separate process. Could
> perhaps set that process to lower priority than the others in the OS?Kjell,
>
There was a similar discussion a few weeks back when someone (Ali?)
wanted to run some process in a lower priority and all these sorts of
ideas were floated.
Process Priority is CPU based. If the particular slow process is CPU
bound then perhaps it would help, but a batch of inserts is likely to
be mostly I/O bound.
One thing Firebird lacks is a customisable scheduling mechanism to
throttle back any query (maybe like a "nice" directive inside a query,
transaction or connection). I am sure it will come one day, but there
is no reliable way at the moment to ensure "batch processes" dont
interfere with "transactional processes".
The best thing to do currently is to throttle it from the client end,
insert 20 records then delay for a second etc. Of course using
paramatised queries or a stored procedure saves Firebird from having
to prepare the query for each execution, and particular useful indices
will get cached pretty quicky, so it is not all bad news.
Adam