|
|
Re: Difference in performance of a SQL Query for same execution plan [message #321624 is a reply to message #321582] |
Tue, 20 May 2008 21:23 |
harrysmall3
Messages: 109 Registered: April 2008 Location: Massachusetts
|
Senior Member |
|
|
Hi Amit,
I am very eager to see the full information as Michel notes for valued analysis but am curious if external factors have come into play such as peak system usage times which plague me at my shop.
Did you run both versions back to back and then after version two, which slowed down, did you switch back to version 1 with same results? With what you presented my instincts scream "concurrent activity" of some sort.
And only because this is a topic of great interest to me do I jump ahead with another blind hypothesis. Is C1 part of a concatonated index with C2 and C3 such that C1 could be retrieved directly from the index in query one, but with the expanded columns the table data blocks now must be accessed?
For some reason this is what popped into my head in replacement of the example columns - a demographic db with c3 = state, c2 = city, c1 = zip code as an index.
then query #1 = select zip code from demo_table where state = val and city = val.
Then the query gets expanded, eg, as select zip code, population, area_size, num_voters where state = same val and city = same val.
Ok, I ramble!
Look forward to hearing more
Regards,
Harry
|
|
|
|
|
|
|
|
|