Subject | Re: [Firebird-Architect] Re: Incremental Backups |
---|---|
Author | Jim Starkey |
Post date | 2004-09-15T14:29:50Z |
Alexandre Kozlov wrote:
was to eliminate the need to manage physical layouts. Other DBMS
systems at that time had extensive options for placement control.
Nobody could ever get it right, so they didn't really help. Mostly they
have the excuse to database developers that their system performance
stunk because the user didn't lay it out correctly. Bosh. Performance
stunk because they offered tradeoffs between three of four mutually
exclusive bad choices.
In most cases, placement control guarentees that the cache hit rate is
minimized and disks seeks are maximized. Claiming you have control over
placement on a non-extent based file system implemented on a raid
controller backed with a three or four gigabyte of physical memory used
for multi-level caches is perposterous. Stuff you hit all the time
lives in memory -- the database page cache, the system disk cache, or
the controller cache. The physical disk accesses are spread all over
the place -- non-continguous files, different physical drives on success
accesses, etc. As a system, it's unpredicatable.
What we do know is that not reading the disk is always faster than
reading the disk.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>It's very important feature of RDBMS to encourage db-developers designing ofI couldn't disagree more. The explicit goal of JRD (DEC and Interbase)
>effective OS-level layout and to help them easier maintaining a big
>databases (with blobs of course) by introducing simple feature into the
>RDBMS - allowing to allocate phisycal space specifically for some selected
>table(s).
>Have this feature ever been considered to be included in FB ?
>Or may it's there already, then sorry.
>
>
>
was to eliminate the need to manage physical layouts. Other DBMS
systems at that time had extensive options for placement control.
Nobody could ever get it right, so they didn't really help. Mostly they
have the excuse to database developers that their system performance
stunk because the user didn't lay it out correctly. Bosh. Performance
stunk because they offered tradeoffs between three of four mutually
exclusive bad choices.
In most cases, placement control guarentees that the cache hit rate is
minimized and disks seeks are maximized. Claiming you have control over
placement on a non-extent based file system implemented on a raid
controller backed with a three or four gigabyte of physical memory used
for multi-level caches is perposterous. Stuff you hit all the time
lives in memory -- the database page cache, the system disk cache, or
the controller cache. The physical disk accesses are spread all over
the place -- non-continguous files, different physical drives on success
accesses, etc. As a system, it's unpredicatable.
What we do know is that not reading the disk is always faster than
reading the disk.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376