"Tim Ellis" wrote in message
> Yes it was the only thing I added (well no it wasn't, but it was the
> only thing I took out again to return to the previous level of
> performance) and yes it is embedded in Cobol.
>
> Karl managed to suggest a solution though. The Selectloop was a
> REPEATED query, and taking the REPEATED clause out fixed the problem -
> the suggestion is that (a) because the query is REPEATED the optimiser
> takes longer to produce a query plan and (b) the ENDSELECT in some way
> invalidates the plan, causing it to be re-optimised every time.
I disagree with Karl only cautiously (well, this time anyway). But all that
sounds like baloney. In the first place I've never heard of such a thing,
it certainly isn't desirable, and it couldn't happen without someone writing
a lot of code to make it work wrong. And in the second place, even if the
optimizer took *up to* 10 times longer because it is a repeated query, it
still wouldn't account for the scale of slow-down you saw.
A much more plausible explanation is that the first query has atypical
parameters and the optimizer chooses and caches a plan that actually stinks
for typical cases. Why it only started to be a problem when you added the
ENDSELECT is a mystery but I'd rather think it was a coincidence than think
that I've misunderstood repeated queries for 20 years.
(I guess my idea of "cautiously" includes calling something baloney. It is
really only a cunning plan to provoke Karl into giving chapter and verse on
it.)
Roy
>> Stay informed about: Select Loop - Endselect takes longer?