Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcnc!ece-csc!ncrcae!ncr-sd!hp-sdd!hplabs!oracle!bradbury
From: bradbury@oracle.UUCP (Robert Bradbury)
Newsgroups: comp.databases
Subject: Long text/binary data columns and performance
Message-ID: <316@oracle.UUCP>
Date: Mon, 13-Jul-87 13:53:31 EDT
Article-I.D.: oracle.316
Posted: Mon Jul 13 13:53:31 1987
Date-Received: Wed, 15-Jul-87 00:38:04 EDT
References: <851@rtech.UUCP> <11872@aero.ARPA> <711@cod.UUCP>
Organization: /usr/lib/news/organization
Lines: 45
Keywords: long columns, performance

This is in response to an article about a month and a half ago.
(Problems with our news connection prevented an earlier response).

In article <711@cod.UUCP>, walker@cod.UUCP (Janet M. Walker) writes:
> 
> We would like sophisticated 4GL capability AND GOOD PERFORMANCE!!  So far I
> haven't  found  the  "best  of all worlds".  There are RDBMS products which
> have capabilities like binary and unlimited  text  data  types  but  slower
> performance,  etc.  I  would  love  to  hear  from vendors and users alike.
> 

Oracle supports a "raw" data type which allows a column up to 65k bytes.
Support for raw data in tools like SQL*FORMS (the screen manager) and
SQL*PLUS (the basic sql interface) is limited for the basic reason that
manipulating a 65K row on a 24x80 screen is ill-defined.  Calls are
provided in the Host Language Interface to manipulate these large columns.

The performance of a DBMS with a column this large (when they are
capable of handling them) is limited a great deal by the UNIX file system.
(Standard UNIX file systems are not good for reading/writing large
chunks of data; BSD file systems are somewhat better but 65K chunks
is still pushing things.)

Criteria to use in judging whether a database can manipulate large columns
of data effectively might include:
  - Can the database use raw disk partitions?
    (to avoid the overhead of the UNIX file system)
  - Can the row of data be stored in an extent of adjacent disk blocks?
    (to avoid excessive seeking to access individual data blocks)
  - Is there a cache which can hold several rows of data?
    (to avoid having to always read the data from the disk)
  - Is it possible for the data to be read into the cache before it is
    required by the user (i.e. is there read-ahead)?
    (to avoid seek/read delays)

The performance of a DBMS when dealing with large columns (or rows) is
a function of its ability to quickly access and move large chunks of data
from the disk to the user and is closely tied to how well the DBMS takes
advantage of those features provided by the OS for handling large amounts
of data.

-- 
Robert Bradbury
Oracle Corporation
(206) 364-1442                            hplabs!oracle!bradbury