Hi Jim,

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

That was exactly what i wanted to tell. I know, OS level different
thread priorites on all resources can cause a lot of side effects.
The server killer SQL command is SELECT(most freq.used command),
if we can do a good disk page I/O queue sheduling on pure SQL
commands on each command level or role/user level we can keep live
FB responses in multiuser heavy load environments. Only for selects
because in your architecture reads doesn't blocks other operations
if i know it correctly(GC doesn't metter). DB Developers, programmers
are not careful and optimistic on SELECTs but inserts and
updates...

My third ask was related about this issue. There are a lot of select
commands written in applications stupidly, out of control of SQL
experts.
They filling cache pages with their unnecessary pages. There is no
way to say to FB, "hey keep this table in cache memory forever!" to
reduce DISK I/O and incrase performance. For example for small but
effective tables like as departments, blood_groups, states,
relation, languages etc..

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

>

I see.

Thank you for your patient and >563. answers for same issues.

Ali