Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more ➡
Download
Standard view
Full view
of .
Add note
Save to My Library
Sync to mobile
Look up keyword or section
Like this
1Activity
×
0 of .
Results for:
No results containing your search query
P. 1
Indexing and Hashing

Indexing and Hashing

Ratings: (0)|Views: 786|Likes:
Published by Krishna Raghu

More info:

Published by: Krishna Raghu on Dec 09, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, PPT, TXT or read online from Scribd
See More
See less

10/22/2011

pdf

text

original

 
1. Storage Access1. Storage Access
s
BLOCKS
a block is a fixed-length unit
blocks are units for storage allocation and data transfer
database files are organized into blocks
s
BLOCK TRANSFERS
minimize the number of block transfers between the disk andmemory
keep as many blocks as possible in main memory
s
BUFFER
portion of main memory available to store copies of disk blocks
s
BUFFER MANAGER
subsystem responsible for allocating buffer space in main memory
 
Buffer ManagerBuffer Manager
s
Programs call on the buffer manager when they need a blockfrom disk
s
If the block is already in the buffer:
5
the requesting program is given the address of the block inmain memory
s
Otherwise:
1.
the buffer manager allocates space in the buffer for the block
5
discard some other block, if necessary, to make space
5
the block that is thrown out is written back to disk only if it wasmodified since the last time it was fetched or modified
1.
the buffer manager reads the block from the disk to the buffer
passes the address of the block in main memory to requester
 
Buffer-Replacement PoliciesBuffer-Replacement Policies
s
Most operating systems replace the block using the
least recentlyused
(LRU)strategy
use past pattern of block references as a predictor of futurereferences
s
BUT Queries have well-defined access patterns
e.g. sequential scans
a database system can use the information in a user’s query to
predict 
future references
s
LRU can be a bad strategy for access patterns that involve repeatedscans of tables
e.g. when computing the join of 2 relations r and s by a nestedloopsfor each tuple
tr 
of
dofor each tuple
ts 
of
doif the tuples
tr 
and
ts 
match …
Mixed strategy with hints on replacement strategy provided by the query optimizer is preferable 

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->