RE: ANTs Data Server?
- From: "Mohan, Ross" <RMohan@xxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 1 Sep 2004 10:59:56 -0400
I agree with that 100%.
(Gosh, stop and consider the sheer
*courage* required to agree with
Cary on something :-P).
A lot of the "molasses-point" stuff I've seen is not
in my 15 tb san with 24 Gb of cache, it's in my sad and
sorry little Sun cpus, apocryphally named "Ultra Sparcs".
( Must describe their final catastrophic failure mode and
concomitant fireworks.)
There's a great little article "out there"
ftp://ftp.cs.wisc.edu/wwt/vldb99_dbms_eval.pdf
"Abstract
Recent high-performance processors employ sophisticated
techniques to overlap and simultaneously execute multiple
computation and memory operations. Intuitively, these
techniques should help database applications, which are
becoming increasingly compute and memory bound. Unfortunately,
recent studies report that faster processors do not improve
database system performance to the same extent as scientific
workloads. Recent work on database systems focusing on
minimizing memory latencies, such as cache-conscious algorithms
for sorting and data placement, is one step toward addressing
this problem. However, to best design high performance DBMSs
we must carefully evaluate and understand the processor and
memory behavior of commercial DBMSs on today's hardware platforms.
In this paper we answer the question "Where does time go when a
database system is executed on a modern computer platform?"
We examine four commercial DBMSs running on an Intel
Xeon and NT 4.0. We introduce a framework for analyzing
query execution time on a DBMS running on a server with
a modern processor and memory architecture. To focus on
processor and memory interactions and exclude effects
from the I/O subsystem, we use a memory resident database.
Using simple queries we find that database developers should
(a) optimize data placement for the second level
of data cache, and not the first,
(b) optimize instruction placement to reduce
first-level instruction cache stalls, but
(c) not expect the overall execution time to
decrease significantly without addressing stalls
related to subtle implementation issues (e.g.,
branch prediction).
"
-----Original Message-----
From: Cary Millsap [mailto:cary.millsap@xxxxxxxxxx]
Sent: Wednesday, September 01, 2004 9:59 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: ANTs Data Server?
I just don't get the whole "cache everything, and everything will be ok"
argument. The vast majority of the slow tasks I've seen in the past ten
years have all executed "in cache" to begin with!
...And fixing them has, almost every time, required either optimization = of
SQL, or optimization of the application code that calls the SQL. I just
don't see how /any/ database can defend itself against all the types of
abuse that an application developer can throw at it.
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *
Upcoming events:
- Performance Diagnosis 101: 9/14 San Francisco, 10/5 Charlotte, 10/26
Toronto
- SQL Optimization 101: 9/20 Hartford, 10/18 New Orleans
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx = [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Peter Robson
Sent: Wednesday, September 01, 2004 8:14 AM
To: Jonathan Gennick
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: ANTs Data Server?
Jonathan,
Wednesday, September 1, 2004, 2:03:04 PM, you wrote:
JG> Has anyone ever heard of these guys?
JG> http://www.antssoftware.com/index.htm
No, I have not heard of them.
The web site refers to in-memory products, and Cache immediately springs to
mind. If you have ever looked at that product, and can remember Adabas,
there are remarkable similarities. The key question to ask of these vendors
is what data model their product supports. The answers can be interesting...
peter
edinburgh
.............
--=20
mailto:pgro@xxxxxxxxx
*********************************************************************
This e-mail message, and any files transmitted with it, are confidential =
and intended solely for the use of the addressee. However, the information
contained in this e-mail may subsequently be subject to public = disclosure
under the Freedom of Information Act 2000 and, unless the information is
legally exempt from disclosure, the confidentially of this e-mail and = your
reply cannot be guaranteed. If this message was not intended for you, = you
have received it in error and any copying, distribution or other use of =
any part of it is strictly prohibited. Any views or opinions presented are
solely those of the sender and do not necessarily represent those of = the
British Geological Survey. The security of e-mail communication = cannot
be guaranteed and the BGS accepts no liability for claims arising as a
result of the use of this medium to transmit messages from or to the = BGS.
http://www.bgs.ac.uk
*********************************************************************
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
