A group of students get some card-stock pages with data on them, each one representing an 8K data or index page. With these, we go through a number of database read operations and look at the IOs that are generated.
This is a great exercise, because it focuses attention on IO, rather than computation.
However, I found that the students had some trouble differentiating between a physical IO and a logical IO. Or realizing that an IO was either logical or physical, and wasn't be both.
So I came up with a chili-cooking analogy.
Suppose I am cooking chili and need a can of kidney beans.
If I go to my cupboard, and there is no can of beans, then I'll need to get in the car and go to the store.
Dang.
That would be like a physical IO. The can of beans is not in my cupboard, and it's a pain (in time and effort) to go to the store for the can of beans.
If I go to the cupboard, and the can of beans is already there, then I don't need to go to the store.
Cool.
That would be like a logical IO. The can of beans is right there handy, and I don't need to spend the time and effort to go to the store.
This is not a perfect analogy, but it has some good parallels.
- I need a can of beans. This is like the SQL Engine needing a data page. It would be considered an IO request. But we don't yet know whether it will be a logical or physical IO.
- The can is in my cupboard or it is not.
- It's in my cupboard. This is like a logical IO. No reason to go to disk (store).
- It's not in my cupboard. This is like a physical IO. Have to go to the disk (store).
So I'm either going to the store (physical IO) or I'm not (logical IO).
So why count logical IOs?
Well, logical IOs are kind of bonus; you can't count on them. (Sometimes that can of beans is in the cupboard, and sometimes its not.) If you have an operation that takes 1000 IOs, it might be all physical IOs the first time, and all logical the next time. So, you should be looking at total IOs as a measure of potential IOs for the operation.
No comments:
Post a Comment