Re: Designing database tables for performance?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 07 Mar 2007 15:56:58 GMT
Message-ID: <ehBHh.7521$PV3.68167_at_ursa-nb00s0.nbnet.nb.ca>


Walt wrote:

> "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.

Thus what some folks call logical I/O neither happens at the logical level of discourse nor does any I/O. Received on Wed Mar 07 2007 - 16:56:58 CET

Original text of this message