operand which is itself a query.Ifthe parser returns withoutanyerrors detected,the OPTIMIZER component iscalled.TheOPTIMIZER accumulates thenames oftables and columns referenced inthe query and looks them up in the System Rcatalogs toverify their existence and toretrieve information about them.Thecatalog lookup portion of theOPTIMIZER also obtains statistics about thereferenced relations, and the access paths‘available oneach of them. These will beused later in access path selection.Aftercataloglookup has obtained the datatypeand lengthof each column, theOPTIMIZERrescans theSELECT-list and WHERE-tree tocheck for semantic errors and type compati-bilityin bothexpressions and predicatecomparisons.Finally theOPTIMIZER performsaccesspath selection.It first determines theevaluation order among the query blocks inthe statement. Then for each query block,therelations in the FROMlist areprocessed. If there is more than onerelation ina block, permutations
thejoin order and of the method of joining areevaluated.The access paths that minimizetotal cost for the blockare chosen from atree ofalternate pathchoices.Thisminimum cost.solution is representedby astructural modification of the parse tree.The result is an executionplan in the
Specification Language (ASLI <lo>.After
plan is chosen foreach queryblock and represented inthe parse tree,theCODE GENERATOR iscalled. TheCODEGENERATOR s a table-driven program whichtranslates ASL treesinto machine languagecodeto execute the plan chosen by theOPTIMIZER. Indoing this it usesa rela-tively small number ofcode templates, onefor each type of join method (including nojoin). Query blocks for nested queries aretreated as"subroutines" which returnvalues to the predicates inwhich theyoccur.TheCODEGENERATOR isfurtherdescribed in <9>.During code generation,the parse treeis replaced by executablemachine code anditsassociateddatastructures.Eithercontrol isimmediately transferedto thiscodeor thecode isstoredaway inthedatabase for laterexecution,depending ontheorigin ofthestatement (program orterminal). Ineither case, whenthe codeis ultimatelyenecuted, it callsupon the
R internal storage
(RSS) viathe storage system interface(RSII to scaneach of the physicallystored relations inthequery.Thesescans arealongtheaccess paths chosen bythe OPTIMIZER.TheRSI commands that maybe used by generatedcode are described in the next section.
_T'he Research Storaae SystemTheResearch StorageSystem (RSSI isthe storagesubsystem of System R.It isresponsibleformaintainingPhysicalstorage
relations,access paths on theserelations, locking(in amulti-user
ronment),and loggingand recovery facili-ties.The RSSpresents atuple-orientedinterface (RSII to its users.Although theRSS
be usedindependently of
R,weare concernedherewithits use
executing the code generated by the proces-singof SQLstatements inSystem R, asdescribed in the previous section.
acomplete description of the RSS, see <l>.Relationsarestoredin the RSS as acollection oftupleswhosecolumnsarephysicallycontiguous.Thesetuplesarestored on
byte pages; no tuplespans apage.Pagesare organizedintologicalunitscalledsegments.Segmentsmaycontainone or
span a segment.Tuples
Each tuple istaggedwiththeidentification of the relationto which itbelongs.The'primary way ofaccessing tuples inarelation isvia anRSSscan.
scanreturns a tuple ata timealong agivenaccess path.OPEN, NEXT, and CLOSE are theprincipal commands on a scan.Twotypes
scans are currentlyavailable
SQL statements. The firsttypeis a segment scan tofind all
tuples ofa given relation.
segment scan simply examines allpages ofthe segment which contain tuples,
any relation, and returns those tuplesbelonging to the given relation.The second typeof scan is an indexscan.An index
be created by a.Sy.stemR useron one or more columns ofa rela-tion, anda relation may haveany number(including
of indexes on it. Theseindexes arestored on separate pages
thosecontaining the relationtuples.Indexes areimplemented asB-trees
pages containing sets of(key,identifiersof tuples .. which containthat
aseries of NEXTs onan index scan doesa sequential read alongthe leaf Pages ofthe index,obtaining thetuple identifiers matching a key, and usingthem to find and returnthe data tuples tothe userin key value
chained togetherso that NEXTsneedinot reference any upper level Pages Ofthe i,ndex.In asegment scan, all thenon-emptypage5 of a segment will be touched. regard-less
whether there are anytuples fromthe
pageis touchedonly once.When anentire relationis enaminedvia anindexscan,each pageof theindex istouched