> one of the problems we used to see every now
> and then - was the following.
> If a table/tables that were being used in a query after an initial
> connections had a lot of triggers defined, the query initialisation would
> take a little bit of time, or a lot of time depending on the number of
> triggers. All trigger code for table/tables that were going to be used in a
> query were loaded into memory first, before the query executed.
Would it load the triggers into memory if the triggers were not going to be
used (e.g. a SELECT)?
I think you might be onto some thing here. If the first query I do is to a
table that has no triggers, it returns as expected, but the first time I do a
'select' that includes one or more tables that have triggers (even if they
are just before insert ones), the big delay returns.
> 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. If
> it does - that's the answer.
The problem is the same for both CS/Linux and SS/Windows. If
Interbase/firebird is loading the all triggers/SP's on first connect this is
fine, but if it loads them the first time a 'table with a trigger' is
encountered, this might explain my issue.
Cheers
Phil
--
Linux 2.4.4-4GB
10:12am up 21 days, 7:56, 2 users, load average: 1.15, 0.59, 0.32