Re: Options for poorly performing SQL

From: Sandra Becker <sbecker6925_at_gmail.com>
Date: Thu, 7 Feb 2013 12:50:51 -0700
Message-ID: <CAJzM94A5O_aM-ZwhUvQkVKM5sRC4Phsqtuh9eMguk8-uUb59Qw_at_mail.gmail.com>



Good point. Bad SQL with a good plan. Therein lies one of the problems. Most of the developers think because the plan is good, so is the SQL. Every time we hire a new developer, I go through the same exercise of explaining and proving that a good plan doesn't necessarily equate to good performance.
On the up side of things, the VP of Development told me this week that they will be rewriting the entire suite of reports, which includes this problem query, and hopes to have that project complete by July. Although, he didn't say July of what year... [?]

Sandy

On Mon, Feb 4, 2013 at 3:39 PM, Job Miller <jobmiller_at_yahoo.com> wrote:

> You don't say whether this is a bad SQL statement or a bad plan from a SQL
> statement.
>
> If you rewrote the SQL to get the same result set smarter, that's
> different than you re-writing the statement so that the same statement is
> optimized better and gets a better plan.
>
> bad plans can be fixed with profiles, but bad SQL with a good plan can
> only be fixed with a query rewrite or a materialized view/query-rewrite
> technique to make the bad sql more efficient.
>
> Job
>

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Feb 07 2013 - 20:50:51 CET

Original text of this message