Fragment Exclusion
Posted in 1999
Topics: Storage & Space Management
I would like a sanity check on my fragmentation scheme. Does anyone know why the following fragmentation clause would NOT allow fragment exclusion in a select. I know if you have a default clause Informix can't exclude fragments, but I think the 'OR' is supported in fragment exclusion. Example Select: Select * from mytable where history = 0; This select should only look at the k1 fragment. fragment by expression (history = '0' ) in k1 , (history = '1' ) in h1 , (history = '2' ) in h2 , (history = 'A' or history = 'B' ) in h1999 , (history = 'C' ) in h2000 extent size 32 next size 16384 lock mode row; -- Kevin H. Hunt khhunt@hunts.com
Kevin Hunt wrote: > > I would like a sanity check on my fragmentation scheme. Does anyone know > why the following fragmentation clause would NOT allow fragment exclusion in > a select. I know if you have a default clause Informix can't exclude > fragments, but I think the 'OR' is supported in fragment exclusion. > > Example Select: Select * from mytable where history = 0; > This select should only look at the k1 fragment. > > fragment by expression > (history = '0' ) in k1 , > (history = '1' ) in h1 , > (history = '2' ) in h2 , > (history = 'A' or history = 'B' ) in h1999 , > (history = 'C' ) in h2000 > extent size 32 next size 16384 lock mode row; Is the 'O' hard coded or a replaceable parameter, ie is the statement: PREPARE stmt FROM "SELECT * FROM mytable WHERE history = ?"; In this case the replaceable parameter is preventing fragment elimination because the value of history is NOT known at PREPARE time but only at the time of the OPEN statement when it is supplied by the USING clause. Art S. Kagel