Subject Re: SQL Performance help
Author Adam
--- In, Helen Borrie <helebor@...> wrote:
> At 12:45 PM 6/11/2006, you wrote:
> > > FWIW, I recommend that you keep right away from a solution that
> > > requires joining to or subquerying stored procedures. I would
> > > lie down in front of a train.
> > >
> > >
> >
> >Hi Helen
> >
> >I got your email after posting my solution (which does use a joined
> >SP). The performance is great and since I cant use FB2s derived tables
> >(yet) then it seems a reasonable solution. Why shouldn't I join a
SP or
> >do you like lying down in from of trains :)
> 1. The SP has to complete before the joining can begin
> 2. Can't use indexes for the join since an SP outputs virtual data
> An SP is cool for this kind of job - as long as you make sure it does
> the whole of the job. Indexes will be used *inside* the SP.
> And, no, being run over by a train is not my preferred way to
>'s just preferable to *that* alternative. :-)

Death by an un-indexed join, I know a couple of fb_inet_server
instances that met that sad fate. Didn't realise it was cross species
to human though.

In this case, it seems to me to be a quite reasonable solution,
providing he allows for point 1. As it will be a left join from the
stored procedure to the table, and there is no where clause involving
the stored procedure (so no index would be used anyway).

Would using derived tables (if available) come up with a plan any
different to the IN clause anyway?