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

restarted.

>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

SuperServer

>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