Path: utzoo!attcan!uunet!dev!dgis!jkrueger From: jkrueger@dgis.dtic.dla.mil (Jon) Newsgroups: comp.arch Subject: Re: 64-bit addresses Message-ID: <785@dgis.dtic.dla.mil> Date: 5 Mar 90 17:22:54 GMT References: <1786@gannet.cl.cam.ac.uk> Organization: Defense Technical Information Center (DTIC), Alexandria VA Lines: 31 pcg@odin.cs.aber.ac.uk (Piercarlo Grandi) writes: >Let me disagree. Unfortunately almost all databases for which a >mainframe is worth having are so immense that their working set is >always much larger than real memory available. You misunderstand. I do not refer to keeping things resident. Query optimization, for instance has to do with minimizing search paths, not optimizing use of fast store (although good query optimizers do figure in costs of network latencies). If your database is large, you might concern yourself with avoiding unnecessary search components. For another example, deferred writes have to do with the timing characteristics of disks, such as the interesting fact that it costs about as much to write a byte as it does to write a bunch of them. If your database is large and active, you might find this method worthwhile. Neither method depends on large memory with respect to database size. Thus either would be particularly appropriate for cases where the opposite will always be true. Perhaps I misled you by my mention of the memory costs of avoiding i/o. This is simply a reference to the space required to store the code that computes the query execution plan, the data that's waiting to synchronize a table update with a committed logged write, and so on. None of this space represents storage for the database at any time. Buffering, for instance, might count as such. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger The Philip Morris Companies, Inc: without question the strongest and best argument for an anti-flag-waving amendment.