Ann W. Harrison wrote:

> Kjell Rilbe wrote:
>>:-) You should have more faith in Firebird!
>
> No doubt, Firebird or more likely Arno... 850 criteria - I would have
> guessed that would explode in the compiler.

*hehe* Perhaps it sounds worse than it is when I say it like that. The
structure of the query is pretty straightforward:

where (FieldA = X
or FieldA = Y
...
or FieldA = Z)
and (FieldB = a
or FieldB = b
...
or FIeldB = c)
and exists (
select *
from Child
where Master.Id = Child.Id
and (ChildField = aa
or ChildField = ab
...
or ChildField = ag)

So, when I say 850 criteria I count X, Y, ... Z, a, b, ..., c, aa, ab,
..., ag, etc. The number of columns tested is at most around 15 and the
query would look a lot nicer if I used the in construct. The reason I
don't is 1) I've previously run into limitations in explicit list size
so they'd have to be split up and 2) I haven't had time to make this
improvement to my SQL generating code.

>>It seems to be runnig nicely on super server. Why classic?
>
> I hadn't got to the bit where you mentioned that everything was
> serialized. The advantage of classic is a bit more parallelism and, in
> the case of local inserts, a much shorter code path. I've been looking
> at a problem that involves very high insert rates over short periods of
> time, so I have code path length on the brain.

Interesting. But classic has the overhead of starting a new process for
every new connection, right? So even with high insert rates, super
server might be more efficient if the clients close and reopen their
connections frequently? On the other hand, why would anyone write a DB
client like that? :-) In fact, I think I should modify my server
application to keep the connection longer than it currently does.

Thanks for the insight.
Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64