|
|
|
@inproceedings{DBLP:conf/vldb/CarinoO98,
author = {Felipe Cari{\~n}o and
William O'Connell},
editor = {Ashish Gupta and
Oded Shmueli and
Jennifer Widom},
title = {Plan-Per-Tuple Optimization Solution - Parallel Execution of
Expensive User-Defined Functions},
booktitle = {VLDB'98, Proceedings of 24rd International Conference on Very
Large Data Bases, August 24-27, 1998, New York City, New York,
USA},
publisher = {Morgan Kaufmann},
year = {1998},
isbn = {1-55860-566-5},
pages = {690-695},
ee = {db/conf/vldb/CarinoO98.html},
crossref = {DBLP:conf/vldb/98},
bibsource = {DBLP, http://dblp.uni-trier.de}
}
Object-Relational database systems allow users to define new user-defined types and functions. This presents new optimizer and run-time challenges to the database systemon shared-nothing architectures. In this paper, we describe a new strategy we are exploring for the NCR Teradata Multimedia Database System; our focus is directing research for realapplications we are seeing. In doing so, we will briefly describe optimizer challenges particularly related to predicate use of large multimedia objects, such as video/audio clips, images, and text documents. The motivation for this work is based on database tuning [SD96] for diverse queries related to multimedia objects. Most notably, expensive and/or high variant user defined functions [Hel98].
Our approach is referred to as plan-per-tuple. The primary focus being on large objects used as predicate-based terms when a non co-located join is involved in the query. But can also be applicable in non co-located join scenarios also. The execution engine can choose from among N! resource optimization strategies; where N represents system manageable resources. In our case, the N resources are: (i) interconnect saturation levels, (ii)available physical memory, (iii) CPU utilization, and (iv) available disk spool space percentages. However, this technique can be applied to any system resources being managed. The optimizer search space does not include these N! resource optimizationstrategies per'se, these are execution engine run-time optimization strategies. When the optimizer identifies expensive, or more importantly a high variant, user- defined function in the predicate (via collected statistics), then the optimizer can generate plans that incorporate plan-per-tuple optimization for that particular compiled query. When executing the plan, a different execution strategy can be used per tuple; the available execution choices do not necessarily equal N! Wedescribe when such an overhead for run-time selection is acceptable.
Copyright © 1998 by the VLDB Endowment. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the VLDB copyright notice and the title of the publication and its date appear, and notice is given that copying is by the permission of the Very Large Data Base Endowment. To copy otherwise, or to republish, requires a fee and/or special permission from the Endowment.
