Re: Hints
- From: Greg Rahn <greg@xxxxxxxxxxxxxxxxxx>
- To: ian@xxxxxxxxxxxxxxxxx
- Date: Tue, 16 Aug 2011 14:39:47 -0700
Cases like this warrant further investigation - as with any execution
plan change. For whatever reason, a faster executing plan was found,
take the time to understand why this is the case. Is it a stats
related thing? Is it because the costing model assumes something that
is not correct in this environment? Is it related to the current
environment resource limitations?
Tim's comments/rants are completely valid in my opinion (perhaps
harsh, but fair) - way too many people just blindly apply something
(like "best practices"), then circulate their "solution" on the
Internet. Nowhere is there any analysis of the problem, nowhere is
there data from before or after, etc. because that is hard stuff - but
it's these things that separates the true experts from the rest. I
certainly discount "empirical" stories if there is no data to support
the observations. Then the community spends the next 10 years trying
to stomp out the "sins of the past." It's really time to raise the
bar and embrace being data-driven.
On Tue, Aug 16, 2011 at 2:05 PM, MacGregor, Ian A.
<ian@xxxxxxxxxxxxxxxxx> wrote:
> I very much agree with what has been said, though some was a bit over the
> top. Here's the situation: A database is handling about 2800 connections
> per minute peak. These are not light-weight connections, but are pulling
> together information from on the fly user defined conic sections of the
> celestial sphere. The connections themselves come from perhaps 1000 client
> machines in a batch farm. The data is then processed via a pipeline
> controlled by the database which controls the order of the processing, and
> weeds out redundant steps.
>
> Shortly after this started one of the physicists had been ready one of Tim's
> old posts. He wanted to see what would happen if we the unmentionable
> parameter was changed. I advised against it, but finally thought that such a
> change would probably make the system worse. It did not, things improved
> dramatically. Oh we have a few queries where the buffer gets count are
> out-of-this-world. But overall the change turned out to be positive. I
> think the real problem was taking of the OS stats at a not so busy time.
> However the chances of reverting the parameter is not good.
>
>
> ________________________________________
> From: Greg Rahn [greg@xxxxxxxxxxxxxxxxxx]
> Sent: Monday, August 15, 2011 1:53 PM
> To: tim@xxxxxxxxx
> Cc: neil_chandler@xxxxxxxxxxx; MacGregor, Ian A.; oracle-l@xxxxxxxxxxxxx
> Subject: Re: Hints
>
> Or to put it another way: "make sure the scope of the solution matches
> the scope of the problem".
--
Regards,
Greg Rahn
http://structureddata.org
--
//www.freelists.org/webpage/oracle-l
Other related posts:
