Subject Re: [IB-Architect] Classic vs SuperServer was IB/FB Lock manager failures
Author Jim Starkey
At 07:20 AM 9/19/02 -0400, Paul Schmidt wrote:
>It would seem to me, that we could cache the compiled statements, and simply
>empty the cache when a DDL statement gets executed or the database is
>However saying that I have run big complex queries that prepared in under
.1 sec,
>so caching the prepared statement might save .01 sec per query, and the
safety of
>not having to compare almost identical statements and goofing it up, isn't
worth the
>time saved, or the memory used to cache the results.

First of all, thanks for the complement. I spent a lot of time
making the compiler fast. The problem is that the compiler
is memory allocation intensive. In simple classic, that is
no problem because I also sweated blood to make the memory
allocated fast. In a threaded world, however, the memory
heap must be protected with a mutex that must be siezed and
released on every block allocated. What works nicely for
classic can become a hog in a threaded environment.

It isn't necessary to do a fancy tree walk to find almost identical
statements. Do a string compare (after a hash lookup) for absolutely
identical. Keep a list of referenced tables with each compiled
statement to re-validate privileges and allow cheap invalidation
after a meta-data tweak. But the payback is limited unless
the cache can be shared over many attachments. (And, yes,
Netfrastructure has this optimization.)

>The question with a single multi-threaded process, is that will an SMP
machine be
>able to run different threads on different CPUs? If so, what's holding
>back, from being able to do that now?

In Linux threads are implemented as separate processes sharing
a single virtual address space. They definitely get scheduled
on different processors. If you think writing fine granuality
code is hard, making it scream on a multi-processor is a gas.

Jim Starkey