Ali Gökçen wrote:

>Setting query-thread priority from client.
>can we set running priority of a query in SQL syntax?
>for example:
>i don't care about the invoice service pressing ivoices in rush hour
>in fast or slow, because printing machines allready very slow,
>and it doesn't metter if it is pressed in 20 minutes or 22 minutes.
>So, it will be nice if i give priority into their applications SQL
>commands. They won't sense the difference but other users will get
>faster response because of that 2 minutes.
>
>

Controlling thread priority rarely has the effect desired. There are
two problems, both near insurmountable. One is the case where a high
priority thread is blocked by a resource held by a low priority thread
that can't get enough CPU to release the resource, effectively
deadlocking the high priority thread. This is a well know operating
system scheduling problem, and is generally addressed by making
priorities dynamic, so the low priority process temporarily assumes the
priority of the process it is blocking. This requires both the ability
to change priorities and a good knowledge of the wait-for graph, neither
of which a database engine has. The second problem is operating system
disk operations don't have priority. Any reasonable database system is
disk bound, so priorities are effectively enforced by the disk system,
not the thread scheduler.

Thread priorities make sense only you have something like an I/O
scheduling thread that you want to give priority over computational
thread. Almost any other use of thread priority tend to fail.

>Second:
>There is a feature in oracle(hippopotamus, who tries to fly as
>Firebird) Point-In-Time, you know. (db level transactions)
>I don't need it but there is a
>goverment specifications that captured from oracle features
>documents. I think it's implementation is much easy in FB because of
>MGA architecture.
>

We've looked at this maybe a half dozen times over the history of
Interbase. The problem is that data versioning is highly application
specific and that most, if not all, models require that the versioning
data be visible. This precludes an automatic, under-the-covers
solution. Another problem, probably more serious, is the "simple"
solution stops the garbage collection process, rapidly rendering a
volatile database unusable.

Data versioning requires a much coarse level of granularity that
individual updates, and visibility needs to be under application
control. The multi-generational architecture isn't the way to implement it.