×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 12/7/2017 1:53 PM, Steinmetz, Paul wrote:
It's actually a combination of everything, but IO is the biggest culprit.
I/O is typically the bottleneck because I/O is orders of magnitude
slower than memory operations.
Paul, I know that you have software from vendors, so you can't control
the way I/O is implemented. Those of us who write our own applications
can though. Imagine a customer table with a hundred columns. Name,
address, multiple email, phone, etc.
How many bytes get transferred off the disk, into an I/O buffer, into
program fields with this statement:
CUSTID CHAIN CUSTOMER
Several thousand bytes for that I/O operation. Now, create a logical or
view that has only name and address, like we use so often. How many
bytes are transferred now?
CUSTID CHAIN ADDRESS
Yeah, a hundred or two. It's quite an improvement. Works with SQL, too:
SELECT NAME, ADDRESS
-vs-
SELECT *
tl;dr I/O isn't just rows, it's rows * columns * bytes per column.
As an Amazon Associate we earn from qualifying purchases.