Subject Re: [IBO] Setting ourselves up for a speed trap
Author hans@hoogstraat.ca
Hello Geoff,

> We have to have something left to do, otherwise why would anyone pay
> us :-)

Depends who recommended IB6. Can be a tough spot to be in.
My time was simple DOS or OS2

> 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.

Fudge driven development.

It was just a question and I wish to stay optimistic too
and also believe the last internet security loophole was
found yesterday :)

Best Regards
Hans

================================================

Geoff Worboys wrote:
>
> > aren't we setting ourselves up for a speed trap by
> > sneakily taking advantage of an IB6 weakness.
>
> It may not be as bad as that. The reason for using fudges like this
> 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 lot
> > of speed using the weakness.
>
> At the risk of stating the obvious. Any upgrade should be done
> 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, Triggers
> > somewhere to quickly retest them for speed and change
> > them, if required.
> >
> > Rolling back denpendent procedures/triggers can be a joy.
>
> We have to have something left to do, otherwise why would anyone pay
> us :-)
>
> Geoff Worboys
> Telesis Computing
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/