|
|
Posted by othellomy on 04/02/07 03:25
On Mar 30, 8:51 pm, "Zamdrist" <zamdr...@gmail.com> wrote:
> On Mar 30, 8:31 am, Ed Murphy <emurph...@socal.rr.com> wrote:
>
>
>
> > If your query is the same as what the application runs, except for
> > specific values being plugged in here and there, then the application
> > will generally get the same execution plan that you do.
>
> > Does QA run your query reasonably quickly? Based on the Profiler
> > trace, does the application seem slow because it runs slow queries,
> > or because it runs an inefficiently large number of queries which
> > are reasonably fast individually?
>
> Here is the query I ran, it returns 70.8K rows in 2 seconds via QA:
>
> Select M.MatterID From Matters M
> Inner Join MatterConflicts MC On MC.Matters = M.Matters
> Inner Join Matters M2 On M2.Matters = MC.HitMatters
> Inner Join MatterConflictHits MCH On MCH.MatterConflicts =
> MC.MatterConflicts
>
> Now the application is doing all kinds of things, probably more
> complicated than my query above. Honestly I don't know enough about
> Profiler to isolate one operation. I did check it out and there are
> many, many sp_cursorexecute, prepare and close statements, along with
> many select fields from tables queries.
>
> I dunno, I doubt I will be able to make any sort of significant impact
> on performance without access to the code.
>
> FYI: This program is a legal case management software called Prolaw by
> Thomson-Elite...it *sucks* royally! LOL.
Cursors are slow. If it is opening cursors on tables with million rows
then I am afraid there is not much you can do. Besides, opening a
cursor on a table with million records even with indexes can be slow
and I don't think the application developers had performance issue on
their mind when they wrote the code initially. Besides, handling most
of the processing on client side without stored procedures will also
slow things down considerably especially for large tables.
Navigation:
[Reply to this message]
|