D. Bitton, et al., "Benchmarking Database Systems: A Systematic Approach", Proc. 9th VLDB, Nov 1983.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....server registries. Our approach is to define a basic set of operations, then combine those operations in meaningful ways to provide synthetic workloads. The basic operations include requests for content (queries) updates to content, connect, deletion, etc. in the form of a database benchmark [4] The requests for content are based on documented use scenarios, that is, the types of requests legitimate users of the grid may ask. A key goal of the work is to test a broad range of functionality of the underlying storage and access medium. A synthetic workload has limitations. It cannot ....

Dina Bitton, David J. DeWitt, and Carolyn Turbyfill. Benchmarking database systems: A systematic approach. Technical report, University of Wisconsin, Computer Sciences Dept., Madison, Wisconsin, 1983.

....measured the execution time of programs instrumented by our dynamic code coverage tools including the setup time for control flow graph generation, dominator tree construction, and instrumentation code insertion. We tested code coverage for PostgreSQL, an object relational DBMS, using the Wisconsin[9] and crashme[2] benchmarks, the C programs and two of the Fortran programs from the SPEC95 benchmarks[4] Experiments were conducted on a SUN SPARC ULTRA 10 with 500MB of main memory, and compiled with gcc version 2.95.1 with debug option enabled. We also measured the total number of basic blocks ....

D. Bitton, D. J. DeWitt, and C. Turbyfill, "Benchmarking Database Systems - A Systematic Approach," Ninth International Conference on Very Large Data Bases. Oct. 31-Nov. 2, Florence, Italy.

....Times were based on the Seagate Barracuda disk used in the prototype. Sega95] For the 2D case, indexes were used when specified and required to enforce unique fields. For all other cases, exhaustive reads were used. 8. 3 Benchmark Description Three benchmarks were selected: The Wisconsin [Bitt83] The Set Query [Oneil91] TPC D H [Raab94] 8.3.1 Wisconsin We chose the 5 queries for which results were reported (and that were not joins) as reasonable representatives of an I O limited case. Selections of 1 and 10 were defined. Also, the benchmark called for the entire record to be ....

Bitton, D., D.J. Dewitt, C.Turbyfill, "Benchmarking Database Systems, a Systematic Approach", Proc of the International Conference on VLDB, Florence, Italy 1983

....situations by using synthetic data, in this paper it is shown that, at least in some cases, one can generate spatio temporal data sets that simulate real world behavior. Much work has been done towards data generation for benchmarks in prototype and commercial non spatio temporal databases [3], 6] 7] 9] 10] 14] 16] 19] These generated data can be used to test different implementations under various operating conditions. In STDBs, the work on the generation of test data is limited and only a few innovative papers have appeared in the literature. In Theodoridis et al. 21] ....

D. Bitton, D.J. DeWitt, and C. Turbyfill. "Benchmarking database systems: a systematic approach," Proceedings 9th VLDB Conference, 8-19, Florence, Italy, 1983.

....this join query, we vary the parallelization strategy, the number of processors used, the shape of the query tree, and the size of the problem. 4. 1 Test data and query The join query studied in this performance evaluation consists of ten relations that contain equal numbers of Wisconsin tuples [BDT83]. These tuples consist of two unique integer attributes and a number of other attributes up to a total size of 208 bytes per tuple. The ten relations are joined one by one on their first integer attributes, and after each join they are projected to the second integer attributes and the remaining ....

D. Bitton, D. J. DeWitt & C. Turbyfill, "Benchmarking database systems - A systematic approach," in Proc 9t VLDB Conf, Florence, Italy, October 31-November 2, 1983.

....avoid heavy daytime Internet traffic that would cause excessive bandwidth and latency variance. The results in this section were generated using a simple synthetic dataset and workload. The database consists of three tables, R1, R2 and R3. The tables are part of the Wisconsin Benchmark database [BITT83], modified to produce results of the sizes indicated in Table 5. We make available statistics that allow a query optimizer to estimate the size of (R1 join R2) R2 join R3) and (R1 join R2 join R3) as 1 MB, 3 MB and 4.5 MB, respectively. The workload query is an equijoin of all three tables: WAN ....

Bitton, D., DeWitt, D. J. and Turbyfill, C., "Benchmarking Data Base Systems: A Systematic Approach," Proc. 9th Int. Conf. on Very Large Data Bases, Florence, Italy, Nov. 1983.

....the 14 database was copied to its assigned processor. The two algorithms were then tested against the data. As the hash join doesn t expect any particular declustering method we used the same scheme for the hash experiments. We used the format of the Wisconsin Benchmark Database for our test data [BITT83]. The records consist of 13 4 byte integers and 3 52 byte character strings. The join attribute was selected to be the first integer, and had a domain range of 0 49,999. 5.3. Results In our comparison of the two algorithms we measured scalability, performance at various levels of memory ....

D. Bitton, D.J. DeWitt, and C. Turbyfill, Benchmarking Database Systems - a Systematic Approach, Proceedings of the 1983 Very Large Database Conference, October 1983.

....speci cations of Transaction Processing Council (TPC, born in 1985) benchmarks. They are mainly used by commercial DBMS providers to publish the best ocial marks they can get in the ever running competition for global performances. The second, following the Wisconsin benchmark s initiative (Bitton et al. 1983 ) sets more the basis of a methodology instead of providing a complete speci cation for a general purpose benchmark. We will use the terms user satisfaction oriented or TPC like benchmarks, and system analysis oriented or Wisconsin like benchmarks, to respectively refer to the two streams. ....

D. Bitton, D. DeWitt and C. Turbyll. Benchmarking Database Systems: A Systematic Approach. In Proceedings of the 9th Conference on Very Large Databases, Morgan Kaufman pubs. (Los Altos CA), Florence, 1983, pp. 8-19.

....functions to prefetch. CGP uses CGHC only at function boundaries, and uses next N line (NL) prefetching to prefetch instructions within a function boundary. We evaluate the effectiveness of CGP using a subset of CPU 2000 benchmarks and a database workload that consists of a subset of the Wisconsin [3] and TPC H [8] queries. Our performance evaluations show that most CPU 2000 benchmarks do not need any prefetching since these benchmarks suffer very few I cache misses. On the other hand, the database workloads do suffer a significant number of Icache misses, and CGP improves their performance ....

....L1 hit latency(cycles) 1 L2 hit latency(cycles) 16 Mem latency (cycles) 80 Branch Predictor 2 lev,2K entry Table 1. Microarchitecture Parameter Values To evaluate the performance of CGP we used a database workload that consists of eight queries (1 through 7 and 9) from the Wisconsin benchmark [3], and five queries (1,2,3,5, and 6) from the TPC H benchmark [8] Wisconsin queries 1 through 7 are 1 and 10 range selection queries (with and without indices) and query 9 is two way join query. The selected TPC H queries include queries with aggregations and many joins, and also includes a ....

D. Bitton, D. DeWitt, and C. Turbyfill. Benchmarking Database Systems A Systematic Approach. In 9th International Conference on Very Large Data Bases, pages 8--19, October 1983.

....(8.5 Mips, each having 256 KB cache memory) 96 MB main memory and 1 GB disk storage. Processors, memory and I O boards are interconnected by a 100 MB s bus. We used a database composed of eighteen relations, generated automatically following the specifications of the standard Wisconsin Benchmark [2]. Tuples are 208 bytes long, and relation cardinality is fixed to 10,000 tuples except for the probing relation of the first join which has 1000 tuples. The size of the intermediate relation of each join is the size of smaller operand relation due to the join predicate. Thus the size of ....

D. Bitton, D.J. DeWitt, and C. Turbyfill. Benchmarking database systems - a systematic approach. In Proc. Int. Conf. on Very Large Databases, 1983.

No context found.

C. Bitton, D. DeWitt, and C.Turbyfill. Benchmarking database systems - a systematic approach. In Proceedings of the 1983 VLDB Conference, October 1983.

....basic operations on this machine and relevant system parameters are summarized in Table 1. To validate the simulation model we present the performance of both a 10 selection query and a join query in a system with 1 30 processors with disks. Expanded versions of the Wisconsin Benchmark relations [BITT83] serve as the test database. The selection query retrieves 100,000 tuples from a 1,000,000 tuple relation and stores the resulting tuples back into the database. As shown in Figure 11, the simulation model matches with observed Gamma performance very closely for this query. However, the actual ....

Bitton, D., D.J. DeWitt, and C. Turbyfill, "Benchmarking Database Systems - A Systematic Approach," Proceedings of the 1983 Very Large Database Conference, October, 1983.

....basic operations on this machine and relevant system parameters are summarized in Table 1. To validate the simulation model we present the performance of both a 10 selection query and a join query in a system with 1 30 processors with disks. Expanded versions of the Wisconsin Benchmark relations [BITT83] serve as the test database. The selection query retrieves 100,000 tuples from a 1,000,000 tuple relation and stores the resulting tuples back into the database. As shown in Figure 11, the simulation model matches with observed Gamma performance very closely for this query. However, the actual ....

Bitton, D., D.J. DeWitt, and C. Turbyfill, "Benchmarking Database Systems - A Systematic Approach," Proceedings of the 1983 Very Large Database Conference, October, 1983.

....processing techniques. Gamma is a fully operational prototype whose design is based on what we learned from building our earlier multiprocessor database machine prototype (DIRECT) and several years of subsequent research on the problems raised by the DIRECT prototype. Our evaluation of DIRECT [BITT83] showed a number of major flaws in its design. First, for certain types of queries, DIRECT s performance was severely constrained by its limited I O bandwidth. This problem was exaggerated by the fact that DIRECT attempted to use parallelism as a substitute for indexing. When one looks at indices ....

....With I O bandwidth a critical resource in any database machine [BORA83] the approach used by DIRECT, while ############################# 1 Rumor has it that Teradata has spent almost 40 million dollars developing their machine. 2 conceptually appealing, leads to disastrous performance [BITT83]. The other major problem with DIRECT was that the number of control actions (messages) required to control the execution of the parallel algorithms used for complex relational operations (e.g. join) was proportional to the product of the sizes of the two input relations. Even with message passing ....

Bitton D., D.J. DeWitt, and C. Turbyfill, "Benchmarking Database Systems - A Systematic Approach," Proceedings of the 1983 Very Large Database Conference, October, 1983.

No context found.

D. Bitton, et al., "Benchmarking Database Systems: A Systematic Approach", Proc. 9th VLDB, Nov 1983.

No context found.

D. Bitton, et al., "Benchmarking Database Systems: A Systematic Approach", Proc. 9th VLDB, Nov 1983.

No context found.

Bitton, D., et al., "Benchmarking Database Systems: A Systematic Approach", 9th VLDB, Nov. 1983.

No context found.

D. Bitton, D.J. DeWitt, and C. Turbyfill. Benchmarking database systems: A systematic approach. In Proceedings, 9th International Conference on Very Large Databases, pages 8--19, Florence, Italy, October 1983. Morgan-Kaufmann.

No context found.

BITTON, D., DEWITT, D. J., AND TURBYFILL, C. Benchmarking database systems a systematic approach. In Large Data Bases, Florence, Italy. (1983), pp. 8--19.

No context found.

D. Bitton, D. J. DeWitt, and C. Turbyfill, Benchmarking Database Systems: A Systematic Approach, Proc. 9th VLDB Conference, Florence, Italy , 1983, 8-19.

No context found.

David DeWitt, Dina Bitton, and Carolyn Turby ll. Benchmarking database systems: A systematic approach. In Proceedings of the 1983 Very Large Database Conference, October 1983.

No context found.

D. Bitton, D. DeWitt, and C. Turbyfill. Benchmarking Database Systems A Systematic Approach. In 9th International Conference on Very Large Data Bases, pages 8--19, October 1983.

No context found.

D. Bitton, D. J. DeWitt, and C. Turbyfill. Benchmarking Databases Systems: A Systematic Approach. In Proc. of Intl. Conf. on Very Large Data Bases, pages 8--19, 1983.

No context found.

Bitton e. al, Benchmarking Database Systems - a systematic approach, in proceedings VLDB 1983

No context found.

Bitton, D., D.J. DeWitt, and C. Turbyfill, "Benchmarking Database Systems - A Systematic Approach". Proceedings of the 1983 Very Large Database Conference, October, 1983.

First 50 documents  Next 50

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