M. Stonebraker and M. A. Olson. Large Object Support in POSTGRES. In Int. Conf. on Data Engineering, pages 355--362, 1993.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....has been finally recognised that objects in OO models are mapped onto the relational model through the typing of the domains of fields, not as generalisations of tables. Extensive typing is now supported in object relational database management systems, led by the work of Stonebraker, for example, [34]. To illustrate typing, consider a sales demand forecasting decision problem, such as mentioned at the end of Section 3. In order to represent the concept Forecast it would usually be treated as a binary predicate with fields for the product identification (the primary key) and the forecast ....

Stonebraker, M., Olson, M. Large Object Support in POSTGRES. ICDE (1993) 355-362

....file level migration scheme. Although global information systems have recently attracted strong attention, little research has been done on the design of the file system for huge image repositories. One of the major efforts is the SEQUIOA 2000 under development at UC Berkeley in the U.S. 1][2]. NASA is also one of the major sites archiving huge amounts of information[3] Both are attempting to build file systems to support the EOS (Earth Observing System) project, where it is expected that 1 TBytes of satellite data per day will be received by the year 2000. But none of them are ....

Stonebraker, M., and Olson, M., "Large Object Support in POSTGRES, Proc. 9th Int'l Conf. on Data Engineering, Vienna, Austria, April 1993.

....from the array. The encoding used is constant rate. Vin and Rangan [18] analyze a method of interleaving data on disk to make the most of disk bandwidth but do not address variable rate streams. Another class of systems that include support for video include several research and commercial DBMSs [15] [2] 1] Some of these systems support sophisticated query by image content features, but do not support real time data delivery the essential feature of Calliope. 5 Conclusions In this paper, we have sketched the architecture and performance characteristics of Calliope a distributed, ....

M. Stonebraker and M. Olson. Large object support in POSTGRES. In Ninth International Conference on Data Engineering, 1993.

....This is a result of a simple device driver implementation; programmer resources to modify the driver to release the SCSI bus on media change operations were not available. Such media swaps can take many seconds to complete. 7. 1 Large object performance The benchmark of Stonebraker and Olson [17] tested HighLight s performance with large objects , measuring I O performance on relatively large transfers. To compare HighLight to the basic LFS mechanism, the benchmark ran with three basic configurations: 1. The basic 4.4BSD LFS. 2. The HighLight version of LFS, using files that have not ....

Michael Stonebraker and Michael Olson. Large Object Support in POSTGRES. In Proc. 9th Int'l Conf. on Data Engineering, Vienna, Austria, April 1993. To appear. 46

....into the system, we designed them so that user can also define their own functions and register them with the database. POSTGRES also supports a wide variety of abstract data types. It has several different implementations of large objects all of which are accessed via typical file operations [12]. Although large objects can include photographs, video streams, and documents, we focus on full text documents and use the External large object type in this implementation. The External type stores the full path name of the external file in the large object column and does not copy the file into ....

Stonebraker, M. and Olson, M. "Large Object Support in POSTGRES" Proceedings of 9th International Conference on Data Engineering, Vienna, Austria, April 1993.

....a generalized interface for multidimensional arrays. Postgres is well suited for handling massive amounts of data; it supports large objects that allow attributes to span multiple pages and it has a generalized storage structure that supports huge capacity storage devices as tertiary memory [STON93]. In our implementation, arrays are first class objects. Therefore any attribute of a class can be declared to be an array of any base type. The internal representation of arrays is a variable length structure with the following fields: int array size int ndim int array dim int array lbound ....

....of results is for a local 1 GB magnetic disk using the Ultrix file system. The block size, C was set to 8 KB, which is the file system block size. A second set of results was taken from data stored on a write once optical jukebox [SON89] the tertiary storage device currently supported by Postgres [STON93]. The jukebox consists of 50 double sided platters, each of which has a 3.27 GB capacity per side. At any time a maximum of two platters can be physically mounted, and mounting a platter takes about ten seconds. A custom storage manager transfers data between disk and tertiary memory in units of ....

Michael Stonebraker and Michael Olson. Large Object Support in POSTGRES. Proc. 9th Intl. Conf. on Data Engineering, April 1993, Vienna, Austria.

....from the SCSI bus, and any media swap transactions hog the SCSI bus until the robot has finished moving the cartridges. Such media swaps can take many seconds to complete. 6.1. Large object performance To test performance with large objects , we used the benchmark of Stonebraker and Olson [15] to measure I O performance on relatively large transfers. It starts with a 51.2MB file, considered a collection of 12,500 frames of 4096 bytes each (these could be database data pages, compressed images in an animation, etc) The buffer cache is flushed before each phase of the benchmark. The ....

Michael Stonebraker and Michael Olson. Large Object Support in POSTGRES. In Proc. 9th Int'l Conf. on Data Engineering, Vienna, Austria, April 1993. To appear.

....treats the disk LFS as a cache for the tertiary storage one. Highlight should give excellent performance on a workload that is write mostly. This should be an excellent match to the Sequoia 2000 environment, whose clients want to archive vast amounts of data. The second file system is Inversion [Ston93a], which is built on top of the POSTGRES DBMS. Like most DBMSs, POSTGRES supports binary large objects (blobs) which can contain an arbitrary number of variable length byte strings. These large objects are stored in a customized storage system directly on a raw (i.e. non file structure) storage ....

M. Stonebraker and M. A. Olson. Large object support in POSTGRES. In Proceedings of the 1993 International Conference on Data Engineering, Vienna, Austria, April 1993. (to appear).

....Inversion takes advantage of these two capabilities to provide strong typing on user files, and to support classification functions that describe files. The Device Manager Switch POSTGRES allows administrators to incorporate new storage devices by writing a small set of interface routines [STON93, OLSO92]. Based on the bdevsw switch in UNIX, the POSTGRES device manager switch registers the devices that are available to the database system. For each device, the required interface routines are listed. These routines are specific to the database system, and include, for example, code to create new ....

....served by the same DECsystem 5900, and political considerations made it impossible to reconfigure the Ultrix NFS server for this test. Another sensible strategy would be to run the benchmark on local file systems, so that network communication costs and the benefit of PRESTOserve were eliminated. [STON93] presents the results of such a benchmark on a 12 processor Sequent Symmetry machine running the Dynix operating system. Those results show that Inversion 10 1993 Winter USENIX January 25 29, 1993 San Diego, CA Olson The Inversion File System gets better than 90 of the throughput of the ....

Stonebraker, M., and Olson, M., "Large Object Support in POSTGRES", Proc. 9th Int'l Conf. on Data Engineering, Vienna, Austria, April 1993 (to appear).

.... ordered force out and synchronous write so that DBMS supported transaction management can function correctly and efficiently. POSTGRES has been written so it can function under either the model in Figure 1 or the model in Figure 2. Moreover, it has several notions for supporting large objects [STON92]. Hence, support for files can be provided as suggested in Figure 3. Here, a hierarchical file system is supported on top of the DBMS. The basic notion is to support two DBMS classes: DIRCTORY (file name, file id, parent file) STORAGE (file id, large object) The first DBMS class supports the ....

Stonebraker, M,. and Olson, M., "Large Object Support in POSTGRES," (in preparation).

No context found.

M. Stonebraker and M. A. Olson. Large Object Support in POSTGRES. In Int. Conf. on Data Engineering, pages 355--362, 1993.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC