----- Original Message -----
From: "Jim Starkey" <jas@...>
To: <Firebird-Architect@yahoogroups.com>
Sent: Wednesday, September 15, 2004 10:29 AM
Subject: Re: [Firebird-Architect] Re: Incremental Backups


>
>
> Alexandre Kozlov wrote:
>
> >It's very important feature of RDBMS to encourage db-developers designing
of
> >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.
> >
> >
> >
> I couldn't disagree more. The explicit goal of JRD (DEC and Interbase)
> 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.

I'm talking about big databases (when memory cache is small in comparison to
size of DB). And sorry, I don't mention it but meant (as supposed it moset
probably should be in large databases) that 95 percent of DB size occupied
with blobs. And so suggested to put it differently to significantly speed up
searching and raise up maintainability. And are your suggestion
(implementation actually) is not the same what I told about ? Here it is.
<snip from your previous post>
>I have probably mentioned it earlier, but Netfrastructure has a feature
>called a blob repository. A repository is a separate set of database
>files for holding blobs

So, for Netfrastructure it's accepteable but for FB not. Sound like this ?

Alexander

>
> 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
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
> E1-I: This message has been scanned for viruses and dangerous content by
UML's antivirus scanning services.
>
>
>