Re: Index Fragmentation strategy

"Art S. Kagel" <kagel@ns1.bloomberg.com> offerred: +On Wed, 22 Jul 1998, ART KAGEL, BLOOMBERG/ NEW YORK wrote: + +> ---- Original Msg from: Stefan Weideneder <stefan@weideneder.de> At: 7/22 10:3 +> I can hardly believe this. I found several fragments while I was +> trying to understand, how the optimizer is using the fragmentation +> expressions. I analysed the behaviour at the Informix office with +> version 7.0. + +Odd. I'll have to look into this again to make sure I'm not talking +through my hat here, but I'm pretty confident about the change. I'll keep +you informed. Well, unless Stefan is running on a Sequent, he isn't using version 7.0. That was an early cut at IDS that was only released on Sequent. 7.1 was the first GA release across all platforms. Exactly which version he is running is very important with regards to the behavior under discussion. Art is correct. There was a change somewhere around the 7.2 timeframe. It used to be the case that an "attached" index was any index without it's own frag scheme or dbspace location. An "attached" index had data and index pages intermingled in the same extents. Then it was changed to behave as Art describes, with only unfragmented tables coupled with an index with no frag scheme or dbspace location using "attached" indexes as described above. In fact, if memory serves, you will see "Old Rsam" in the output of oncheck -pT for such tables. Dave ** Dave Kosenko <davek@summitdata.com> ** Director of Training Services (732) 469-4070 ** Summit Data Group (an Informix Authorized Education Center) ** Find my advice useful? Let me teach you everything I know about ** Informix. Sign up for OFFICIAL Informix training at SDG. ** For details, see http://www.summitdata.com/training