Subject | Re: [IBO] Setting ourselves up for a speed trap |
---|---|
Author | Geoff Worboys |
Post date | 2001-08-14T03:10:36Z |
> aren't we setting ourselves up for a speed trap byIt may not be as bad as that. The reason for using fudges like this
> sneakily taking advantage of an IB6 weakness.
is to make it obvious to the IB optimiser that a particular element of
the where clause cannot be used for optimisation.
If there is a "fix" for IB6 optimisation weakness then we hope that
part of the fix will be make a better index selection in the first
place - which may make the fudge redundant, but should not make it a
bad thing.
Just suppose that the IB6 optimiser and engine is somehow enhanced to
try and make good use of simple 'or' clauses - perhaps detecting
static elements that can be ignored, or maybe executing the query in
separate sections (one for each part of the 'or'). Such an
enhancement may make the fudge stop working as intended, but hopefully
such a change will also make better index choices to begin with and
extended processing of 'or' clauses would presumably take second place
to more direct optimisations.
So while I am making a few assumptions in the above paragraphs, I
think they are reaonsable assumptions and changes to optimisation that
did not follow this are very likely to be found unacceptable.
> 1. Never Upgrade IB6 if your application gains a lotAt the risk of stating the obvious. Any upgrade should be done
> of speed using the weakness.
carefully. Despite the fact that IB6 was supposed to provide a smooth
upgrade from IB5.6 there were some very significant items that needed
careful handling and testing.
> 2. Hope next IB6 release is a lot / lot smarter.I am not sure if IB6 is ready to get "smarter". In many respects I
would prefer it to begin by offering the developer a little more
direct control - as is being proposed with FK declarations and
indexes. Once the controls are in place, then some level of
intelligence can be added to make appropriate defaults using those
controls. Just IMHO :-)
> 3. Somehow Localize all your SQL, Procedurer, TriggersWe have to have something left to do, otherwise why would anyone pay
> somewhere to quickly retest them for speed and change
> them, if required.
>
> Rolling back denpendent procedures/triggers can be a joy.
us :-)
Geoff Worboys
Telesis Computing