Re: Designing database tables for performance?

From: Walt <wamitty_at_verizon.net>
Date: Wed, 07 Mar 2007 15:04:23 GMT
Message-ID: <XvAHh.19804$tf.17735_at_trndny06>

"Cimode" <cimode_at_hotmail.com> wrote in message news:1173214333.040736.29540_at_q40g2000cwq.googlegroups.com... On 6 mar, 05:59, "d..._at_smooth1.co.uk" <d..._at_smooth1.co.uk> wrote:
> > The time to complete is therefore far less and the "cost" in terms of

>> time is much less.

> So because time is the difference that makes less physical. Don't you
> see anything wrong in that?

Messages in this discussion have expressed it wrong, but there is a sensible way to describe this situation.

When reference is made to "database data" within a client process, a "logical I/O" takes place regardless of whether a "Physical I/O" takes place or not. The "logical I/O" is the transfer of data between space managed by the agent of the DBMS within the client and space managed by the client process runtime environment. Its convenient to call the former "buffer space" and the latter "working storage".

The Physical I/O is the transfer between persistent secondary storage (e.g. "disk") and "buffer space".

In the case of a Physical I/O immediately followed by a logical I/O, the delay time due to the Physical I/O eclipses the delay due to the logical I/O.

In the case of a buffer already containing the needed data, the logical I/O is the only delay. Something physical *is* happening in the case of logical I/O, BTW. It just isn't I/O. Received on Wed Mar 07 2007 - 16:04:23 CET