Re: Whatcha' wanta have?????

Madison Pruet wrote: > > "Andrew Hamm" <ahamm@mail.com> wrote in message > news:c0p1kf$18fcsm$1@ID-79573.news.uni-berlin.de... > > > Index ANDing. Let's presume an index on the employee table by name and > > > one on department. You want to look up Mr. Smith in marketing. > > > The DBMS first collects all rowid's for Smith and then all for the > > > employees in the marketing department. It can then intersect the sets > > > and go after the real rows. > > > > ummmmmm - ok - if the selectivity of both is quite high, then it can help. > > I'd wager that it help less often than you might think ?? > > Not so sure. > > Way back when I was working for Sperry, the DMS-1100 product had via-set > records that could be stored either as links within the row or in an > index-pointer array. The addresses within the IPA would then point to the > record within the set. > > A common way of improving the selectivity of several set intersections was > to fetch the IPA for the various sets and then select the intersection by > using two way, three way, etc. match/merge of the addresses and then fetch > the actual records via the the reduced address array. It made a significant > improvement in the select/fetch performance. > > The index ANDing is nothing more than a fancy term for what was being done > back with IPAs in the codasyl DBMS days. > very, very true! But who is old enuff to remember how round the wheels had to be when hardware was slow..... Nowaday, if the re-invented wheel isn't a sqare anymore, but more like a heptagramme or better, everyone and her sister celebrated this as best practice. Always a good laugh for the old man, sometimes with tears, though. dic_k -- Richard Kofler SOLID STATE EDV Dienstleistungen GmbH Vienna/Austria/Europe

"Richard Kofler" <richard.kofler@chello.at> wrote in message news:40311902.B18D6F9E@chello.at... > Madison Pruet wrote: > > > > Not so sure. > > > > Way back when I was working for Sperry, the DMS-1100 product had via-set > > records that could be stored either as links within the row or in an > > index-pointer array. The addresses within the IPA would then point to the > > record within the set. > > > > A common way of improving the selectivity of several set intersections was > > to fetch the IPA for the various sets and then select the intersection by > > using two way, three way, etc. match/merge of the addresses and then fetch > > the actual records via the the reduced address array. It made a significant > > improvement in the select/fetch performance. > > > > The index ANDing is nothing more than a fancy term for what was being done > > back with IPAs in the codasyl DBMS days. > > > > very, very true! > But who is old enuff to remember how round the wheels > had to be when hardware was slow..... > Nowaday, if the re-invented wheel isn't a sqare anymore, > but more like a heptagramme or better, everyone and her > sister celebrated this as best practice. > Always a good laugh for the old man, sometimes with tears, > though. Well --- if it made slow hardware run faster, it'd also make faster hardware run even faster... ;-) > > dic_k > > -- > Richard Kofler > SOLID STATE EDV > Dienstleistungen GmbH > Vienna/Austria/Europe