| Title: | DEC Rdb against the World |
| Moderator: | HERON::GODFRIND |
| Created: | Fri Jun 12 1987 |
| Last Modified: | Thu Feb 23 1995 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1348 |
| Total number of notes: | 5438 |
When V3.0 of Rdb was released, it was said that without no tuning V3.0 didn't have much better performance then V2.1. Well tuned it could have 10 times the performance of V2.1. Was it true? What about a well tuned V4.0A and V4.0A with no tuning? Ketil
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1016.1 | NOVA::FEENAN | Jay Feenan, Rdb/VMS engineering | Thu Oct 24 1991 17:32 | 9 | |
the difference in performance, relative to this statement was the
impact on performance relative to I/O bottlenecks in a single file
database environment. 'Tuned' in this sense was basically partition
your data a bit and expect performance. With any database product that
I know of 'tuned' vs. 'untuned' versions of the database show dramatic
changes in performance. So yes the V4.0a statement the you made is
true.
-Jay
| |||||
| 1016.2 | NOVA::NOVA::R_ANDERSON | My timing is Digital. | Fri Oct 25 1991 14:26 | 10 | |
This is a classic problem when issuing new releases of products: In order to remain "fully backward-compatible", all "new features" are usually packaged as a series of "knobs" that can be enabled/disabled by users. This means that with each new release, the difference between "untuned" (the default) versus "tuned" (the attainable) becomes more and more dramatic. The reverse of this problem is that with each new release, there are more and more knobs, thus increasing the difficulty of correctly tuning a database. Rick | |||||
| 1016.3 | NOVA::MOY | Michael G. Moy, Rdb/VMS Engineering | Fri Nov 08 1991 18:56 | 3 | |
3.0 also provided for hashed indexes so with 3.0 it was possible to
access your data in 1 io from an index compared to descending a sorted
index that had to access a data page.
| |||||