> > Would it load the triggers into memory if the triggers were not going to
> > be used (e.g. a SELECT)?
>
> Yes, information about tables is looked up and cached when the relation is
> first referenced by a request. When the request is compiled
<SNIP>
> Then MET_scan_relation is called to
> obtain a significant amount of otable information, including all the
> trigger code.
Test seam to back this up. One thing that is still confusing... are the
triggers cached for all tables, regardless of if that table is not referenced
by a request?
The reason I ask is that, for example, I have two tables with 4 triggers
each. Running a 'query' just after connection on the first table is 'slow',
and then running a 'query' on the second is 'fast'. Does this mean that the
first 'query' is also caching the triggers of the second one? Or does it
mean that the 'caching process' is faster for the second one, because it has
already been initialised by the first? or something else?
> > > Now - does InterBase load all of the Trigger and SP code into memory on
> > > first connect with SuperServer, so it can be shared and re-used later.
>
> Checked the code, it seems to work as above Classic or SuperServer, there
> doesn't seem to any difference (except thread handling) - when the table is
> referenced all the tigger information is loaded.
Thanks for that info, I think I understand what is happening now. The
'issue' I am trying to overcome is that I am implementing connection pooling
to get round the connection overhead, but I need to do a few 'dummy queries'
immediately after connection to get round the caching overhead. It would be
good to have a 'createcache' connection param that does this automatically,
especially in 'web apps', but I would have no idea how feasible this would be.
Many thanks
Phil
--
Linux 2.4.4-4GB
1:39pm up 3 days, 21:19, 1 user, load average: 0.43, 0.28, 0.19