Re: Microsoft destroys TPC-C records!

In comp.databases.sybase Brian Peasland <peasland_at_edcmail.cr.usgs.gov> wrote: >> Shakespeare didn't work with many databases, but I'm sure he'd >> agree that speed is superior to tunability. Still, I've talked with  

> Since when has speed and tunability become mutually exclusive? You can't
> have speed with tunability? Again, another crock of b.s.
 

>>    a lot of people recently who position Oracle as better because it's
>>    "more tunable" than SQL Server. True, Oracle 8i has more than 400
>>    tunable parameters while SQL Server 7.0 has fewer than 50--and that
>>    number drops in SQL Server 2000. The argument is that, because Oracle
>>    offers many more tuning parameters than SQL Server, you can make
>>    Oracle run more efficiently than SQL Server. However, this argument
>>    has a fatal foundational flaw: that "manually tunable" equals
>>    "optimal performance."
 

> I'm sorry, but I'd rather have 400 tunable params than 50 anyday. The
> more control I have over my database the better. And the last thing I
> want is the database performing tuning for me. The database can not, nor
> will it ever, be able to fully understand my applications, how they
> relate and work together.
>

>>    Database administrators and developers easily fall for this
>>    assumption. The engineer deep down inside us desperately wants to
>>    believe that we're smarter than the machine. We love to feel needed
 

> We are smarter than the machine. A computer is only capable of doing
> only what we tell it to do. Nothing more, and unfortunately in some
> cases, nothing less.
 

>>    astonishing performance improvement. But it's time we got over
>>    ourselves. We're not that smart. And most of our tuning successes
>>    have come as a result of working with a database that couldn't do
>>    the job for us.
 

> Most of our tuning successes have come as a result of working with
> technologies that are not up to par with our business needs. These
> technologies are a combination of hardware and software. Part of our job
> is to eke every drop of performance from our techologies when we have
> reached it's limits.
>

>>       Remember when we optimized queries by listing tables and conditions
>>       in a certain order in the FROM and WHERE clauses? Wasn't that "tuning"
>>       the query? Today, no one seems to mind that cost-based optimizers find
>>       the best execution path for our queries. In fact, we'd laugh at a
 

> I seem to mind. While cost based optimization is great and works in most
> cases, it does not always find the best execution path for our queries.
> Thankfully I can go back to rule based queries whenever I want.
 

>>       database product that didn't have a sophisticated cost-based optimizer.
>>       Why don't we expect the database engine to have the same level of
>>       intelligence?
 

> Because it's very hard for a db to fully understand the applications
> that are running against and the users who use the db. After all, how is
> the db to know that I plan on performing a major load this weekend? Or
> that for the next week, I'll be experiencing a 50% increase in the
> number of users?
>

With the rule-based approach, the optimizer chooses whether to use an access path based on these factors:
o the available access paths for the statement o the ranks of these access paths

To choose an access path, the optimizer first examines the conditions in the statemens WHERE clause to determine which access paths are available. The optimizer then chooses the most highly ranked available access path.

Note that the full table scan is the lowest ranked access path on the list. This means that the rule-based approach always chooses an access path that uses an index if one is available, even if a full table scan might execute faster. Received on Tue Apr 11 2000 - 00:00:00 CDT