Slow Query with index

IDS 11.50 FC8X4 Linux I have a query that has been successfully running on an IDS 10.0 for quite some time. We recently moved the database to an 11.5 server, and the result set appears different. For some reason the IDS 10 database seemed to return the data in index order, even tho the index was not clustered. The 11.5 database did not do that, so when we limited the number of rows returned, often the rows we were looking for were not included in the result set. To fix this, I added the 'order by' statement. The result set is now as expected, however, the query takes up to 2 minutes to complete. The index is as indicated.. and update statistics have been run using Art's dostats. select {+INDEX (idx_vehowner, vehicle_owner)} first 100 vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, vo_addr_set_id,vehownindex from vehicle_owner where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and ((vo_last_name = 'WILSON and vo_first_name >= 'RUDOLPH') or (vo_last_name > 'WILSON'))) order by vo_last_name, vo_first_name; create index 'informix'.idx_vehowner on 'informix'.vehicle_owner ( vo_owner_type, vo_last_name asc, vo_first_name asc, vo_middle_name asc ) ; The really strange thing is that if I use a name beginning with 'A', the query is screaming fast. The farther into the alphabet you go, the slower it gets - kind of like it is just scanning through the table in order? there are 7.8 million records in the table. Any suggestions would be helpful! Thanks! Laurie Laurie Gustin Database Administrator Dept of Technology Services Dept of Public Safety lgustin@utah.gov 801-965-4410

On 10 May 2011 16:00, Laurie Gustin <lgustin@utah.gov> wrote: > IDS 11.50 FC8X4 > Linux > > I have a query that has been successfully running on an IDS 10.0 for quite > some time. We recently moved the database to an 11.5 server, and the result > set appears different. For some reason the IDS 10 database seemed to return > the data in index order, even tho the index was not clustered. The 11.5 > database did not do that, so when we limited the number of rows returned, > often the rows we were looking for were not included in the result set. To fix > this, I added the 'order by' statement. The result set is now as expected, > however, the query takes up to 2 minutes to complete. The index is as > indicated.. and update statistics have been run using Art's dostats. > > select {+INDEX (idx_vehowner, vehicle_owner)} > first 100 > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, > vo_addr_set_id,vehownindex > from vehicle_owner > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and > ((vo_last_name = 'WILSON and vo_first_name >= 'RUDOLPH') or (vo_last_name > > 'WILSON'))) > order by vo_last_name, vo_first_name; > > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner > ( vo_owner_type, > vo_last_name asc, > vo_first_name asc, > vo_middle_name asc > ) ; > > The really strange thing is that if I use a name beginning with 'A', the query > is screaming fast. The farther into the alphabet you go, the slower it gets - > kind of like it is just scanning through the table in order? > > there are 7.8 million records in the table. > > Any suggestions would be helpful! > > Thanks! > Laurie > > Laurie Gustin > Database Administrator > Dept of Technology Services > Dept of Public Safety > lgustin@utah.gov > 801-965-4410 > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > Laurie What does the explain plan show for the queries on the two systems, compare and contrast and when you find a difference that is the reason for the the additional time !! Keith

Try adding this index and removing the +INDEX() optimizer directive: create index 'informix'.idx_vehowner on 'informix'.vehicle_owner ( vo_last_name asc, vo_first_name asc, vo_owner_type, vo_middle_name asc ) ; If that doesn't work, post the original and new SET EXPLAIN outputs and we'll take a look. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, May 10, 2011 at 11:00 AM, Laurie Gustin <lgustin@utah.gov> wrote: > IDS 11.50 FC8X4 > Linux > > I have a query that has been successfully running on an IDS 10.0 for quite > some time. We recently moved the database to an 11.5 server, and the result > set appears different. For some reason the IDS 10 database seemed to return > the data in index order, even tho the index was not clustered. The 11.5 > database did not do that, so when we limited the number of rows returned, > often the rows we were looking for were not included in the result set. To > fix > this, I added the 'order by' statement. The result set is now as expected, > however, the query takes up to 2 minutes to complete. The index is as > indicated.. and update statistics have been run using Art's dostats. > > select {+INDEX (idx_vehowner, vehicle_owner)} > first 100 > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, > vo_addr_set_id,vehownindex > from vehicle_owner > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and > ((vo_last_name = 'WILSON and vo_first_name >= 'RUDOLPH') or (vo_last_name > > 'WILSON'))) > order by vo_last_name, vo_first_name; > > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner > ( vo_owner_type, > vo_last_name asc, > vo_first_name asc, > vo_middle_name asc > ) ; > > The really strange thing is that if I use a name beginning with 'A', the > query > is screaming fast. The farther into the alphabet you go, the slower it gets > - > kind of like it is just scanning through the table in order? > > there are 7.8 million records in the table. > > Any suggestions would be helpful! > > Thanks! > Laurie > > Laurie Gustin > Database Administrator > Dept of Technology Services > Dept of Public Safety > lgustin@utah.gov > 801-965-4410 > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --20cf3071d02e3dad8804a2ed66ea

I would be tempted to put the vo_owner_type deeper into the index and = not have the middle name at all in the index. What does the explain plan say? j. On May 10, 2011, at 11:00 AM, Laurie Gustin wrote: > IDS 11.50 FC8X4=20 > Linux=20 >=20 > I have a query that has been successfully running on an IDS 10.0 for = quite=20 > some time. We recently moved the database to an 11.5 server, and the = result=20 > set appears different. For some reason the IDS 10 database seemed to = return=20 > the data in index order, even tho the index was not clustered. The = 11.5=20 > database did not do that, so when we limited the number of rows = returned,=20 > often the rows we were looking for were not included in the result = set. To fix=20 > this, I added the 'order by' statement. The result set is now as = expected,=20 > however, the query takes up to 2 minutes to complete. The index is as=20= > indicated.. and update statistics have been run using Art's dostats.=20= >=20 > select {+INDEX (idx_vehowner, vehicle_owner)}=20 > first 100=20 > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name,=20= > vo_addr_set_id,vehownindex=20 > from vehicle_owner=20 > where ((vo_owner_type =3D 'O' OR vo_owner_type =3D 'E') and=20 > ((vo_last_name =3D 'WILSON and vo_first_name >=3D 'RUDOLPH') or = (vo_last_name >=20 > 'WILSON')))=20 > order by vo_last_name, vo_first_name;=20 >=20 > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner=20 > ( vo_owner_type,=20 > vo_last_name asc,=20 > vo_first_name asc,=20 > vo_middle_name asc=20 > ) ;=20 >=20 > The really strange thing is that if I use a name beginning with 'A', = the query=20 > is screaming fast. The farther into the alphabet you go, the slower it = gets -=20 > kind of like it is just scanning through the table in order?=20 >=20 > there are 7.8 million records in the table.=20 >=20 > Any suggestions would be helpful!=20 >=20 > Thanks!=20 > Laurie=20 >=20 > Laurie Gustin=20 > Database Administrator=20 > Dept of Technology Services=20 > Dept of Public Safety=20 > lgustin@utah.gov=20 > 801-965-4410=20 >=20 >=20 > = **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20= >=20

Thanks for the suggestions... I changed the index, leaving out middle_name altogether and putting type at the end. Then ran the query without the index directive... below is the query plan. Unfortunately, I no longer have access to the old server to compare the old query plan... QUERY: (OPTIMIZATION TIMESTAMP: 05-10-2011 10:22:31) ------ select first 100 vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, vo_addr_set_id,vehownindex from vehicle_owner where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and ((vo_last_name = 'WADSWORTH' and vo_first_name >= 'RALPH') or (vo_last_name > 'WADSWORTH'))) order by vo_last_name, vo_first_name Estimated Cost: 751789 Estimated # of Rows Returned: 481854 Temporary Files Required For: Order By 1) informix.vehicle_owner: INDEX PATH (1) Index Name: informix.idx_vehowner Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) (Serial, fragments: ALL) Lower Index Filter: informix.vehicle_owner.vo_last_name > 'WADSWORTH' Index Key Filters: ((informix.vehicle_owner.vo_owner_type = 'O' OR informix.vehicle_owner.vo_owner_type = 'E' ) ) (2) Index Name: informix.idx_vehowner Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) (Serial, fragments: ALL) Lower Index Filter: (informix.vehicle_owner.vo_last_name = 'WADSWORTH' AND informix.vehicle_owner.vo_first_name >= 'RALPH' ) Index Key Filters: ((informix.vehicle_owner.vo_owner_type = 'O' OR informix.vehicle_owner.vo_owner_type = 'E' ) ) The query still took over 2 minutes. When I run the query with the last name of ANDERSEN, it takes about 1 second... Thanks Laurie >>> "Art Kagel" <art.kagel@gmail.com> 5/10/2011 9:13 AM >>> Try adding this index and removing the +INDEX() optimizer directive: create index 'informix'.idx_vehowner on 'informix'.vehicle_owner ( vo_last_name asc, vo_first_name asc, vo_owner_type, vo_middle_name asc ) ; If that doesn't work, post the original and new SET EXPLAIN outputs and we'll take a look. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, May 10, 2011 at 11:00 AM, Laurie Gustin <lgustin@utah.gov> wrote: > IDS 11.50 FC8X4 > Linux > > I have a query that has been successfully running on an IDS 10.0 for quite > some time. We recently moved the database to an 11.5 server, and the result > set appears different. For some reason the IDS 10 database seemed to return > the data in index order, even tho the index was not clustered. The 11.5 > database did not do that, so when we limited the number of rows returned, > often the rows we were looking for were not included in the result set. To > fix > this, I added the 'order by' statement. The result set is now as expected, > however, the query takes up to 2 minutes to complete. The index is as > indicated.. and update statistics have been run using Art's dostats. > > select {+INDEX (idx_vehowner, vehicle_owner)} > first 100 > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, > vo_addr_set_id,vehownindex > from vehicle_owner > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and > ((vo_last_name = 'WILSON and vo_first_name >= 'RUDOLPH') or (vo_last_name > > 'WILSON'))) > order by vo_last_name, vo_first_name; > > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner > ( vo_owner_type, > vo_last_name asc, > vo_first_name asc, > vo_middle_name asc > ) ; > > The really strange thing is that if I use a name beginning with 'A', the > query > is screaming fast. The farther into the alphabet you go, the slower it gets > - > kind of like it is just scanning through the table in order? > > there are 7.8 million records in the table. > > Any suggestions would be helpful! > > Thanks! > Laurie > > Laurie Gustin > Database Administrator > Dept of Technology Services > Dept of Public Safety > lgustin@utah.gov > 801-965-4410 > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --20cf3071d02e3dad8804a2ed66ea ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

That's a really high estimated cost. Check sysmaster:sysptprof for what happened against this index. The = partnumber is in sysfragments where indexname=3D whatever you called it. What are the datatypes for each of those columns? Varchar by any = chance? j. On May 10, 2011, at 12:32 PM, Laurie Gustin wrote: > Thanks for the suggestions...=20 >=20 > I changed the index, leaving out middle_name altogether and putting = type at=20 > the end. Then ran the query without the index directive... below is = the query=20 > plan. Unfortunately, I no longer have access to the old server to = compare the=20 > old query plan...=20 >=20 > QUERY: (OPTIMIZATION TIMESTAMP: 05-10-2011 10:22:31)=20 > ------=20 > select=20 > first 100=20 > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name,=20= > vo_addr_set_id,vehownindex=20 > from vehicle_owner=20 > where ((vo_owner_type =3D 'O' OR vo_owner_type =3D 'E') and=20 > ((vo_last_name =3D 'WADSWORTH' and vo_first_name >=3D 'RALPH') or = (vo_last_name >=20 > 'WADSWORTH')))=20 > order by vo_last_name, vo_first_name=20 >=20 > Estimated Cost: 751789=20 > Estimated # of Rows Returned: 481854=20 > Temporary Files Required For: Order By=20 >=20 > 1) informix.vehicle_owner: INDEX PATH=20 >=20 > (1) Index Name: informix.idx_vehowner=20 >=20 > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) = (Serial,=20 > fragments: ALL)=20 >=20 > Lower Index Filter: informix.vehicle_owner.vo_last_name > 'WADSWORTH'=20= >=20 > Index Key Filters: ((informix.vehicle_owner.vo_owner_type =3D 'O' OR=20= > informix.vehicle_owner.vo_owner_type =3D 'E' ) )=20 >=20 > (2) Index Name: informix.idx_vehowner=20 >=20 > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) = (Serial,=20 > fragments: ALL)=20 >=20 > Lower Index Filter: (informix.vehicle_owner.vo_last_name =3D = 'WADSWORTH' AND=20 > informix.vehicle_owner.vo_first_name >=3D 'RALPH' )=20 >=20 > Index Key Filters: ((informix.vehicle_owner.vo_owner_type =3D 'O' OR=20= > informix.vehicle_owner.vo_owner_type =3D 'E' ) )=20 >=20 > The query still took over 2 minutes.=20 >=20 > When I run the query with the last name of ANDERSEN, it takes about 1=20= > second...=20 >=20 > Thanks=20 > Laurie=20 >=20 >>>> "Art Kagel" <art.kagel@gmail.com> 5/10/2011 9:13 AM >>>=20 > Try adding this index and removing the +INDEX() optimizer directive:=20= >=20 > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner=20 > ( vo_last_name asc,=20 > vo_first_name asc,=20 > vo_owner_type,=20 > vo_middle_name asc=20 > ) ;=20 >=20 > If that doesn't work, post the original and new SET EXPLAIN outputs = and=20 > we'll take a look.=20 >=20 > Art=20 >=20 > Art S. Kagel=20 > Advanced DataTools (www.advancedatatools.com)=20 > Blog: http://informix-myview.blogspot.com/=20 >=20 > Disclaimer: Please keep in mind that my own opinions are my own = opinions and=20 > do not reflect on my employer, Advanced DataTools, the IIUG, nor any = other=20 > organization with which I am associated either explicitly, implicitly, = or by=20 > inference. Neither do those opinions reflect those of other = individuals=20 > affiliated with any entity with which I am affiliated nor those of the=20= > entities themselves.=20 >=20 > On Tue, May 10, 2011 at 11:00 AM, Laurie Gustin <lgustin@utah.gov> = wrote:=20 >=20 >> IDS 11.50 FC8X4=20 >> Linux=20 >>=20 >> I have a query that has been successfully running on an IDS 10.0 for = quite=20 >> some time. We recently moved the database to an 11.5 server, and the = result=20 >> set appears different. For some reason the IDS 10 database seemed to = return=20 >> the data in index order, even tho the index was not clustered. The = 11.5=20 >> database did not do that, so when we limited the number of rows = returned,=20 >> often the rows we were looking for were not included in the result = set. To=20 >> fix=20 >> this, I added the 'order by' statement. The result set is now as = expected,=20 >> however, the query takes up to 2 minutes to complete. The index is as=20= >> indicated.. and update statistics have been run using Art's dostats.=20= >>=20 >> select {+INDEX (idx_vehowner, vehicle_owner)}=20 >> first 100=20 >> vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, = vo_middle_name,=20 >> vo_addr_set_id,vehownindex=20 >> from vehicle_owner=20 >> where ((vo_owner_type =3D 'O' OR vo_owner_type =3D 'E') and=20 >> ((vo_last_name =3D 'WILSON and vo_first_name >=3D 'RUDOLPH') or = (vo_last_name >=20 >> 'WILSON')))=20 >> order by vo_last_name, vo_first_name;=20 >>=20 >> create index 'informix'.idx_vehowner on 'informix'.vehicle_owner=20 >> ( vo_owner_type,=20 >> vo_last_name asc,=20 >> vo_first_name asc,=20 >> vo_middle_name asc=20 >> ) ;=20 >>=20 >> The really strange thing is that if I use a name beginning with 'A', = the=20 >> query=20 >> is screaming fast. The farther into the alphabet you go, the slower = it gets=20 >> -=20 >> kind of like it is just scanning through the table in order?=20 >>=20 >> there are 7.8 million records in the table.=20 >>=20 >> Any suggestions would be helpful!=20 >>=20 >> Thanks!=20 >> Laurie=20 >>=20 >> Laurie Gustin=20 >> Database Administrator=20 >> Dept of Technology Services=20 >> Dept of Public Safety=20 >> lgustin@utah.gov=20 >> 801-965-4410=20 >>=20 >>=20 >>=20 >>=20 >=20 > = **************************************************************************= *****=20 >> Forum Note: Use "Reply" to post a response in the discussion forum.=20= >>=20 >>=20 >=20 > --20cf3071d02e3dad8804a2ed66ea=20 >=20 >=20 > = **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20 >=20 >=20 > = **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20= >=20

sysptprof says bufreads/writes... no seq scans. The fields are just CHAR columns... >>> "Jack Parker" <jack.parker4@verizon.net> 5/10/2011 10:56 AM >>> That's a really high estimated cost. Check sysmaster:sysptprof for what happened against this index. The = partnumber is in sysfragments where indexname=3D whatever you called it. What are the datatypes for each of those columns? Varchar by any = chance? j. On May 10, 2011, at 12:32 PM, Laurie Gustin wrote: > Thanks for the suggestions...=20 >=20 > I changed the index, leaving out middle_name altogether and putting = type at=20 > the end. Then ran the query without the index directive... below is = the query=20 > plan. Unfortunately, I no longer have access to the old server to = compare the=20 > old query plan...=20 >=20 > QUERY: (OPTIMIZATION TIMESTAMP: 05-10-2011 10:22:31)=20 > ------=20 > select=20 > first 100=20 > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name,=20= > vo_addr_set_id,vehownindex=20 > from vehicle_owner=20 > where ((vo_owner_type =3D 'O' OR vo_owner_type =3D 'E') and=20 > ((vo_last_name =3D 'WADSWORTH' and vo_first_name >=3D 'RALPH') or = (vo_last_name >=20 > 'WADSWORTH')))=20 > order by vo_last_name, vo_first_name=20 >=20 > Estimated Cost: 751789=20 > Estimated # of Rows Returned: 481854=20 > Temporary Files Required For: Order By=20 >=20 > 1) informix.vehicle_owner: INDEX PATH=20 >=20 > (1) Index Name: informix.idx_vehowner=20 >=20 > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) = (Serial,=20 > fragments: ALL)=20 >=20 > Lower Index Filter: informix.vehicle_owner.vo_last_name > 'WADSWORTH'=20= >=20 > Index Key Filters: ((informix.vehicle_owner.vo_owner_type =3D 'O' OR=20= > informix.vehicle_owner.vo_owner_type =3D 'E' ) )=20 >=20 > (2) Index Name: informix.idx_vehowner=20 >=20 > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) = (Serial,=20 > fragments: ALL)=20 >=20 > Lower Index Filter: (informix.vehicle_owner.vo_last_name =3D = 'WADSWORTH' AND=20 > informix.vehicle_owner.vo_first_name >=3D 'RALPH' )=20 >=20 > Index Key Filters: ((informix.vehicle_owner.vo_owner_type =3D 'O' OR=20= > informix.vehicle_owner.vo_owner_type =3D 'E' ) )=20 >=20 > The query still took over 2 minutes.=20 >=20 > When I run the query with the last name of ANDERSEN, it takes about 1=20= > second...=20 >=20 > Thanks=20 > Laurie=20 >=20 >>>> "Art Kagel" <art.kagel@gmail.com> 5/10/2011 9:13 AM >>>=20 > Try adding this index and removing the +INDEX() optimizer directive:=20= >=20 > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner=20 > ( vo_last_name asc,=20 > vo_first_name asc,=20 > vo_owner_type,=20 > vo_middle_name asc=20 > ) ;=20 >=20 > If that doesn't work, post the original and new SET EXPLAIN outputs = and=20 > we'll take a look.=20 >=20 > Art=20 >=20 > Art S. Kagel=20 > Advanced DataTools (www.advancedatatools.com)=20 > Blog: http://informix-myview.blogspot.com/=20 >=20 > Disclaimer: Please keep in mind that my own opinions are my own = opinions and=20 > do not reflect on my employer, Advanced DataTools, the IIUG, nor any = other=20 > organization with which I am associated either explicitly, implicitly, = or by=20 > inference. Neither do those opinions reflect those of other = individuals=20 > affiliated with any entity with which I am affiliated nor those of the=20= > entities themselves.=20 >=20 > On Tue, May 10, 2011 at 11:00 AM, Laurie Gustin <lgustin@utah.gov> = wrote:=20 >=20 >> IDS 11.50 FC8X4=20 >> Linux=20 >>=20 >> I have a query that has been successfully running on an IDS 10.0 for = quite=20 >> some time. We recently moved the database to an 11.5 server, and the = result=20 >> set appears different. For some reason the IDS 10 database seemed to = return=20 >> the data in index order, even tho the index was not clustered. The = 11.5=20 >> database did not do that, so when we limited the number of rows = returned,=20 >> often the rows we were looking for were not included in the result = set. To=20 >> fix=20 >> this, I added the 'order by' statement. The result set is now as = expected,=20 >> however, the query takes up to 2 minutes to complete. The index is as=20= >> indicated.. and update statistics have been run using Art's dostats.=20= >>=20 >> select {+INDEX (idx_vehowner, vehicle_owner)}=20 >> first 100=20 >> vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, = vo_middle_name,=20 >> vo_addr_set_id,vehownindex=20 >> from vehicle_owner=20 >> where ((vo_owner_type =3D 'O' OR vo_owner_type =3D 'E') and=20 >> ((vo_last_name =3D 'WILSON and vo_first_name >=3D 'RUDOLPH') or = (vo_last_name >=20 >> 'WILSON')))=20 >> order by vo_last_name, vo_first_name;=20 >>=20 >> create index 'informix'.idx_vehowner on 'informix'.vehicle_owner=20 >> ( vo_owner_type,=20 >> vo_last_name asc,=20 >> vo_first_name asc,=20 >> vo_middle_name asc=20 >> ) ;=20 >>=20 >> The really strange thing is that if I use a name beginning with 'A', = the=20 >> query=20 >> is screaming fast. The farther into the alphabet you go, the slower = it gets=20 >> -=20 >> kind of like it is just scanning through the table in order?=20 >>=20 >> there are 7.8 million records in the table.=20 >>=20 >> Any suggestions would be helpful!=20 >>=20 >> Thanks!=20 >> Laurie=20 >>=20 >> Laurie Gustin=20 >> Database Administrator=20 >> Dept of Technology Services=20 >> Dept of Public Safety=20 >> lgustin@utah.gov=20 >> 801-965-4410=20 >>=20 >>=20 >>=20 >>=20 >=20 > = **************************************************************************= *****=20 >> Forum Note: Use "Reply" to post a response in the discussion forum.=20= >>=20 >>=20 >=20 > --20cf3071d02e3dad8804a2ed66ea=20 >=20 >=20 > = **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20 >=20 >=20 > = **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20= >=20 ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

While you're up, Could you also post the contents of systables and sysindexes for the = table and index? j. On May 10, 2011, at 12:32 PM, Laurie Gustin wrote: > Thanks for the suggestions...=20 >=20 > I changed the index, leaving out middle_name altogether and putting = type at=20 > the end. Then ran the query without the index directive... below is = the query=20 > plan. Unfortunately, I no longer have access to the old server to = compare the=20 > old query plan...=20 >=20 > QUERY: (OPTIMIZATION TIMESTAMP: 05-10-2011 10:22:31)=20 > ------=20 > select=20 > first 100=20 > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name,=20= > vo_addr_set_id,vehownindex=20 > from vehicle_owner=20 > where ((vo_owner_type =3D 'O' OR vo_owner_type =3D 'E') and=20 > ((vo_last_name =3D 'WADSWORTH' and vo_first_name >=3D 'RALPH') or = (vo_last_name >=20 > 'WADSWORTH')))=20 > order by vo_last_name, vo_first_name=20 >=20 > Estimated Cost: 751789=20 > Estimated # of Rows Returned: 481854=20 > Temporary Files Required For: Order By=20 >=20 > 1) informix.vehicle_owner: INDEX PATH=20 >=20 > (1) Index Name: informix.idx_vehowner=20 >=20 > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) = (Serial,=20 > fragments: ALL)=20 >=20 > Lower Index Filter: informix.vehicle_owner.vo_last_name > 'WADSWORTH'=20= >=20 > Index Key Filters: ((informix.vehicle_owner.vo_owner_type =3D 'O' OR=20= > informix.vehicle_owner.vo_owner_type =3D 'E' ) )=20 >=20 > (2) Index Name: informix.idx_vehowner=20 >=20 > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) = (Serial,=20 > fragments: ALL)=20 >=20 > Lower Index Filter: (informix.vehicle_owner.vo_last_name =3D = 'WADSWORTH' AND=20 > informix.vehicle_owner.vo_first_name >=3D 'RALPH' )=20 >=20 > Index Key Filters: ((informix.vehicle_owner.vo_owner_type =3D 'O' OR=20= > informix.vehicle_owner.vo_owner_type =3D 'E' ) )=20 >=20 > The query still took over 2 minutes.=20 >=20 > When I run the query with the last name of ANDERSEN, it takes about 1=20= > second...=20 >=20 > Thanks=20 > Laurie=20 >=20 >>>> "Art Kagel" <art.kagel@gmail.com> 5/10/2011 9:13 AM >>>=20 > Try adding this index and removing the +INDEX() optimizer directive:=20= >=20 > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner=20 > ( vo_last_name asc,=20 > vo_first_name asc,=20 > vo_owner_type,=20 > vo_middle_name asc=20 > ) ;=20 >=20 > If that doesn't work, post the original and new SET EXPLAIN outputs = and=20 > we'll take a look.=20 >=20 > Art=20 >=20 > Art S. Kagel=20 > Advanced DataTools (www.advancedatatools.com)=20 > Blog: http://informix-myview.blogspot.com/=20 >=20 > Disclaimer: Please keep in mind that my own opinions are my own = opinions and=20 > do not reflect on my employer, Advanced DataTools, the IIUG, nor any = other=20 > organization with which I am associated either explicitly, implicitly, = or by=20 > inference. Neither do those opinions reflect those of other = individuals=20 > affiliated with any entity with which I am affiliated nor those of the=20= > entities themselves.=20 >=20 > On Tue, May 10, 2011 at 11:00 AM, Laurie Gustin <lgustin@utah.gov> = wrote:=20 >=20 >> IDS 11.50 FC8X4=20 >> Linux=20 >>=20 >> I have a query that has been successfully running on an IDS 10.0 for = quite=20 >> some time. We recently moved the database to an 11.5 server, and the = result=20 >> set appears different. For some reason the IDS 10 database seemed to = return=20 >> the data in index order, even tho the index was not clustered. The = 11.5=20 >> database did not do that, so when we limited the number of rows = returned,=20 >> often the rows we were looking for were not included in the result = set. To=20 >> fix=20 >> this, I added the 'order by' statement. The result set is now as = expected,=20 >> however, the query takes up to 2 minutes to complete. The index is as=20= >> indicated.. and update statistics have been run using Art's dostats.=20= >>=20 >> select {+INDEX (idx_vehowner, vehicle_owner)}=20 >> first 100=20 >> vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, = vo_middle_name,=20 >> vo_addr_set_id,vehownindex=20 >> from vehicle_owner=20 >> where ((vo_owner_type =3D 'O' OR vo_owner_type =3D 'E') and=20 >> ((vo_last_name =3D 'WILSON and vo_first_name >=3D 'RUDOLPH') or = (vo_last_name >=20 >> 'WILSON')))=20 >> order by vo_last_name, vo_first_name;=20 >>=20 >> create index 'informix'.idx_vehowner on 'informix'.vehicle_owner=20 >> ( vo_owner_type,=20 >> vo_last_name asc,=20 >> vo_first_name asc,=20 >> vo_middle_name asc=20 >> ) ;=20 >>=20 >> The really strange thing is that if I use a name beginning with 'A', = the=20 >> query=20 >> is screaming fast. The farther into the alphabet you go, the slower = it gets=20 >> -=20 >> kind of like it is just scanning through the table in order?=20 >>=20 >> there are 7.8 million records in the table.=20 >>=20 >> Any suggestions would be helpful!=20 >>=20 >> Thanks!=20 >> Laurie=20 >>=20 >> Laurie Gustin=20 >> Database Administrator=20 >> Dept of Technology Services=20 >> Dept of Public Safety=20 >> lgustin@utah.gov=20 >> 801-965-4410=20 >>=20 >>=20 >>=20 >>=20 >=20 > = **************************************************************************= *****=20 >> Forum Note: Use "Reply" to post a response in the discussion forum.=20= >>=20 >>=20 >=20 > --20cf3071d02e3dad8804a2ed66ea=20 >=20 >=20 > = **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20 >=20 >=20 > = **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20= >=20

OK, here's the problem. The optimzer is treating the inequality filter and the equality filters as if this were a UNION of two separate queries. So it is seeing: select first 100 vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, vo_addr_set_id,vehownindex from vehicle_owner where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and ((vo_last_name = 'WADSWORTH' and vo_first_name >= 'RALPH'))) UNION select first 100 vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, vo_addr_set_id,vehownindex from vehicle_owner where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and ((vo_last_name > 'WADSWORTH'))) order by vo_last_name, vo_first_name; In order to join the two results sets, remove duplicates, and filter for the first 100 rows, the optimizer must collect all of the matching rows from both queries and sort the results. I'm betting that 'ANDERSON' is either the smallest value in vo_last_name or there are more than 100 rows with that value in the column and the optimizer knows that, so it is shortcutting the query. It may even be eliminating the second part of the UNION or merging the two into a single '<=' comparison if you also eliminated the filter on vo_first_name when you substituted 'ANDERSON'. I don't know because you did not supply the query plan for that version of the query. If you eliminate the FIRST 100 clause, does it run faster for 'ROGER' & 'WADSWORTH'? Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, May 10, 2011 at 12:32 PM, Laurie Gustin <lgustin@utah.gov> wrote: > Thanks for the suggestions... > > I changed the index, leaving out middle_name altogether and putting type at > the end. Then ran the query without the index directive... below is the > query > plan. Unfortunately, I no longer have access to the old server to compare > the > old query plan... > > QUERY: (OPTIMIZATION TIMESTAMP: 05-10-2011 10:22:31) > ------ > select > first 100 > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, > vo_addr_set_id,vehownindex > from vehicle_owner > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and > ((vo_last_name = 'WADSWORTH' and vo_first_name >= 'RALPH') or (vo_last_name > > > 'WADSWORTH'))) > order by vo_last_name, vo_first_name > > Estimated Cost: 751789 > Estimated # of Rows Returned: 481854 > Temporary Files Required For: Order By > > 1) informix.vehicle_owner: INDEX PATH > > (1) Index Name: informix.idx_vehowner > > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) (Serial, > fragments: ALL) > > Lower Index Filter: informix.vehicle_owner.vo_last_name > 'WADSWORTH' > > Index Key Filters: ((informix.vehicle_owner.vo_owner_type = 'O' OR > informix.vehicle_owner.vo_owner_type = 'E' ) ) > > (2) Index Name: informix.idx_vehowner > > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) (Serial, > fragments: ALL) > > Lower Index Filter: (informix.vehicle_owner.vo_last_name = 'WADSWORTH' AND > informix.vehicle_owner.vo_first_name >= 'RALPH' ) > > Index Key Filters: ((informix.vehicle_owner.vo_owner_type = 'O' OR > informix.vehicle_owner.vo_owner_type = 'E' ) ) > > The query still took over 2 minutes. > > When I run the query with the last name of ANDERSEN, it takes about 1 > second... > > Thanks > Laurie > > >>> "Art Kagel" <art.kagel@gmail.com> 5/10/2011 9:13 AM >>> > Try adding this index and removing the +INDEX() optimizer directive: > > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner > ( vo_last_name asc, > vo_first_name asc, > vo_owner_type, > vo_middle_name asc > ) ; > > If that doesn't work, post the original and new SET EXPLAIN outputs and > we'll take a look. > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.com) > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and > do not reflect on my employer, Advanced DataTools, the IIUG, nor any other > organization with which I am associated either explicitly, implicitly, or > by > inference. Neither do those opinions reflect those of other individuals > affiliated with any entity with which I am affiliated nor those of the > entities themselves. > > On Tue, May 10, 2011 at 11:00 AM, Laurie Gustin <lgustin@utah.gov> wrote: > > > IDS 11.50 FC8X4 > > Linux > > > > I have a query that has been successfully running on an IDS 10.0 for > quite > > some time. We recently moved the database to an 11.5 server, and the > result > > set appears different. For some reason the IDS 10 database seemed to > return > > the data in index order, even tho the index was not clustered. The 11.5 > > database did not do that, so when we limited the number of rows returned, > > often the rows we were looking for were not included in the result set. > To > > fix > > this, I added the 'order by' statement. The result set is now as > expected, > > however, the query takes up to 2 minutes to complete. The index is as > > indicated.. and update statistics have been run using Art's dostats. > > > > select {+INDEX (idx_vehowner, vehicle_owner)} > > first 100 > > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, > > vo_addr_set_id,vehownindex > > from vehicle_owner > > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and > > ((vo_last_name = 'WILSON and vo_first_name >= 'RUDOLPH') or (vo_last_name > > > > 'WILSON'))) > > order by vo_last_name, vo_first_name; > > > > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner > > ( vo_owner_type, > > vo_last_name asc, > > vo_first_name asc, > > vo_middle_name asc > > ) ; > > > > The really strange thing is that if I use a name beginning with 'A', the > > query > > is screaming fast. The farther into the alphabet you go, the slower it > gets > > - > > kind of like it is just scanning through the table in order? > > > > there are 7.8 million records in the table. > > > > Any suggestions would be helpful! > > > > Thanks! > > Laurie > > > > Laurie Gustin > > Database Administrator > > Dept of Technology Services > > Dept of Public Safety > > lgustin@utah.gov > > 801-965-4410 > > > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --20cf3071d02e3dad8804a2ed66ea > > > > **********************************

Thanks for the insight Art! Still not knowing exactly why this queries performs differently, I took what you said and put it all in a stored procedure that will separate the 'two sides of the union' and only do the second half if needed. It returns a sub-second response - no matter what part of the alphabet you are in.. or how many records for a single last name. Thanks for everyone's help on this!! Laurie Laurie Gustin Database Administrator Dept of Technology Services Dept of Public Safety lgustin@utah.gov 801-965-4410 >>> "Art Kagel" <art.kagel@gmail.com> 5/10/2011 11:17 AM >>> OK, here's the problem. The optimzer is treating the inequality filter and the equality filters as if this were a UNION of two separate queries. So it is seeing: select first 100 vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, vo_addr_set_id,vehownindex from vehicle_owner where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and ((vo_last_name = 'WADSWORTH' and vo_first_name >= 'RALPH'))) UNION select first 100 vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, vo_addr_set_id,vehownindex from vehicle_owner where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and ((vo_last_name > 'WADSWORTH'))) order by vo_last_name, vo_first_name; In order to join the two results sets, remove duplicates, and filter for the first 100 rows, the optimizer must collect all of the matching rows from both queries and sort the results. I'm betting that 'ANDERSON' is either the smallest value in vo_last_name or there are more than 100 rows with that value in the column and the optimizer knows that, so it is shortcutting the query. It may even be eliminating the second part of the UNION or merging the two into a single '<=' comparison if you also eliminated the filter on vo_first_name when you substituted 'ANDERSON'. I don't know because you did not supply the query plan for that version of the query. If you eliminate the FIRST 100 clause, does it run faster for 'ROGER' & 'WADSWORTH'? Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, May 10, 2011 at 12:32 PM, Laurie Gustin <lgustin@utah.gov> wrote: > Thanks for the suggestions... > > I changed the index, leaving out middle_name altogether and putting type at > the end. Then ran the query without the index directive... below is the > query > plan. Unfortunately, I no longer have access to the old server to compare > the > old query plan... > > QUERY: (OPTIMIZATION TIMESTAMP: 05-10-2011 10:22:31) > ------ > select > first 100 > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, > vo_addr_set_id,vehownindex > from vehicle_owner > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and > ((vo_last_name = 'WADSWORTH' and vo_first_name >= 'RALPH') or (vo_last_name > > > 'WADSWORTH'))) > order by vo_last_name, vo_first_name > > Estimated Cost: 751789 > Estimated # of Rows Returned: 481854 > Temporary Files Required For: Order By > > 1) informix.vehicle_owner: INDEX PATH > > (1) Index Name: informix.idx_vehowner > > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) (Serial, > fragments: ALL) > > Lower Index Filter: informix.vehicle_owner.vo_last_name > 'WADSWORTH' > > Index Key Filters: ((informix.vehicle_owner.vo_owner_type = 'O' OR > informix.vehicle_owner.vo_owner_type = 'E' ) ) > > (2) Index Name: informix.idx_vehowner > > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) (Serial, > fragments: ALL) > > Lower Index Filter: (informix.vehicle_owner.vo_last_name = 'WADSWORTH' AND > informix.vehicle_owner.vo_first_name >= 'RALPH' ) > > Index Key Filters: ((informix.vehicle_owner.vo_owner_type = 'O' OR > informix.vehicle_owner.vo_owner_type = 'E' ) ) > > The query still took over 2 minutes. > > When I run the query with the last name of ANDERSEN, it takes about 1 > second... > > Thanks > Laurie > > >>> "Art Kagel" <art.kagel@gmail.com> 5/10/2011 9:13 AM >>> > Try adding this index and removing the +INDEX() optimizer directive: > > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner > ( vo_last_name asc, > vo_first_name asc, > vo_owner_type, > vo_middle_name asc > ) ; > > If that doesn't work, post the original and new SET EXPLAIN outputs and > we'll take a look. > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.com) > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and > do not reflect on my employer, Advanced DataTools, the IIUG, nor any other > organization with which I am associated either explicitly, implicitly, or > by > inference. Neither do those opinions reflect those of other individuals > affiliated with any entity with which I am affiliated nor those of the > entities themselves. > > On Tue, May 10, 2011 at 11:00 AM, Laurie Gustin <lgustin@utah.gov> wrote: > > > IDS 11.50 FC8X4 > > Linux > > > > I have a query that has been successfully running on an IDS 10.0 for > quite > > some time. We recently moved the database to an 11.5 server, and the > result > > set appears different. For some reason the IDS 10 database seemed to > return > > the data in index order, even tho the index was not clustered. The 11.5 > > database did not do that, so when we limited the number of rows returned, > > often the rows we were looking for were not included in the result set. > To > > fix > > this, I added the 'order by' statement. The result set is now as > expected, > > however, the query takes up to 2 minutes to complete. The index is as > > indicated.. and update statistics have been run using Art's dostats. > > > > select {+INDEX (idx_vehowner, vehicle_owner)} > > first 100 > > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, > > vo_addr_set_id,vehownindex > > from vehicle_owner > > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and > > ((vo_last_name = 'WILSON and vo_first_name >= 'RUDOLPH') or (vo_last_name > > > > 'WILSON'))) > > order by vo_last_name, vo_first_name; > > > > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner > > ( vo_owner_type, > > vo_last_name asc, > > vo_first_name asc, > > vo_middle_name asc > > ) ; > > > > The really strange thing is that if I use a name beginning with 'A', the > > query > > is screaming fast. The farther into the alphabet you go, the slower it > gets > > - > > kind of like it is just scanning through the table in

Laurie: You do not need a stored procedure. The following will work, used the stores_demo database as an example schema. select first 100 * from customer where lname >= "Miller" and (case when lname = 'Miller' and fname < "Jane"then 'f' ELSE 't' END)::boolean order by lname, fname John F. Miller III STSM, Embedability Architect miller3@us.ibm.com 503-578-5645 IBM Informix Dynamic Server (IDS) ids-bounces@iiug.org wrote on 05/10/2011 11:49:05 AM: > [image removed] > > Re: Slow Query with index [23626] > > Laurie Gustin > > to: > > ids > > 05/10/2011 11:55 AM > > Sent by: > > ids-bounces@iiug.org > > Please respond to ids > > Thanks for the insight Art! > > Still not knowing exactly why this queries performs differently, I took what > you said and put it all in a stored procedure that will separate the 'two > sides of the union' and only do the second half if needed. It returns a > sub-second response - no matter what part of the alphabet you are in.. or how > many records for a single last name. > > Thanks for everyone's help on this!! > > Laurie > > Laurie Gustin > Database Administrator > Dept of Technology Services > Dept of Public Safety > lgustin@utah.gov > 801-965-4410 > > >>> "Art Kagel" <art.kagel@gmail.com> 5/10/2011 11:17 AM >>> > OK, here's the problem. The optimzer is treating the inequality filter and > the equality filters as if this were a UNION of two separate queries. So it > is seeing: > > select first 100> > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, > vo_middle_name, > > vo_addr_set_id,vehownindex > from vehicle_owner > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') > > and ((vo_last_name = 'WADSWORTH' and vo_first_name >= 'RALPH'))) > UNION > select first 100> > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, > vo_middle_name, > > vo_addr_set_id,vehownindex > from vehicle_owner > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') > > and ((vo_last_name > 'WADSWORTH'))) > order by vo_last_name, vo_first_name; > > In order to join the two results sets, remove duplicates, and filter for the > first 100 rows, the optimizer must collect all of the matching rows from > both queries and sort the results. I'm betting that 'ANDERSON' is either > the smallest value in vo_last_name or there are more than 100 rows with that > value in the column and the optimizer knows that, so it is shortcutting the > query. It may even be eliminating the second part of the UNION or merging > the two into a single '<=' comparison if you also eliminated the filter on > vo_first_name when you substituted 'ANDERSON'. I don't know because you did > not supply the query plan for that version of the query. If you eliminate > the FIRST 100 clause, does it run faster for 'ROGER' & 'WADSWORTH'? > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.com) > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions and > do not reflect on my employer, Advanced DataTools, the IIUG, nor any other > organization with which I am associated either explicitly, implicitly, or by > inference. Neither do those opinions reflect those of other individuals > affiliated with any entity with which I am affiliated nor those of the > entities themselves. > > On Tue, May 10, 2011 at 12:32 PM, Laurie Gustin <lgustin@utah.gov> wrote: > > > Thanks for the suggestions... > > > > I changed the index, leaving out middle_name altogether and putting type at > > the end. Then ran the query without the index directive... below is the > > query > > plan. Unfortunately, I no longer have access to the old server to compare > > the > > old query plan... > > > > QUERY: (OPTIMIZATION TIMESTAMP: 05-10-2011 10:22:31) > > ------ > > select > > first 100 > > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, > > vo_addr_set_id,vehownindex > > from vehicle_owner > > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and > > ((vo_last_name = 'WADSWORTH' and vo_first_name >= 'RALPH') or (vo_last_name > > > > > 'WADSWORTH'))) > > order by vo_last_name, vo_first_name > > > > Estimated Cost: 751789 > > Estimated # of Rows Returned: 481854 > > Temporary Files Required For: Order By > > > > 1) informix.vehicle_owner: INDEX PATH > > > > (1) Index Name: informix.idx_vehowner > > > > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) (Serial, > > fragments: ALL) > > > > Lower Index Filter: informix.vehicle_owner.vo_last_name > 'WADSWORTH' > > > > Index Key Filters: ((informix.vehicle_owner.vo_owner_type = 'O' OR > > informix.vehicle_owner.vo_owner_type = 'E' ) ) > > > > (2) Index Name: informix.idx_vehowner > > > > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) (Serial, > > fragments: ALL) > > > > Lower Index Filter: (informix.vehicle_owner.vo_last_name = 'WADSWORTH' AND > > informix.vehicle_owner.vo_first_name >= 'RALPH' ) > > > > Index Key Filters: ((informix.vehicle_owner.vo_owner_type = 'O' OR > > informix.vehicle_owner.vo_owner_type = 'E' ) ) > > > > The query still took over 2 minutes. > > > > When I run the query with the last name of ANDERSEN, it takes about 1 > > second... > > > > Thanks > > Laurie > > > > >>> "Art Kagel" <art.kagel@gmail.com> 5/10/2011 9:13 AM >>> > > Try adding this index and removing the +INDEX() optimizer directive: > > > > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner > > ( vo_last_name asc, > > vo_first_name asc, > > vo_owner_type, > > vo_middle_name asc > > ) ; > > > > If that doesn't work, post the original and new SET EXPLAIN outputs and > > we'll take a look. > > > > Art > > > > Art S. Kagel > > Advanced DataTools (www.advancedatatools.com) > > Blog: http://informix-myview.blogspot.com/ > > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > > and > > do not reflect on my employer, Advanced DataTools, the IIUG, nor any other > > organization with which I am associated either explicitly, implicitly, or > > by > > inference. Neither do those opinions reflect those of other individuals > > affiliated with any entity with which I am affiliated nor those of the > > entities themselves. > > > > On Tue, May 10, 2011 at 11:00 AM, Laurie Gustin <lgustin@utah.gov> wrote: > > > > > IDS 11.50 FC8X4 > > > Linux > > > > > > I have a query that has been successfully running on an IDS 10.0 for > > quite > > > some time. We recently moved the database to an 11.5 server, and the > > result > > > set appears different. For some reason the IDS 10 database seemed to > > return > > > the data in index order, even tho the index was not clustered. The 11.5 > > > database did not do that, so whe

Neat trick John. I like it! Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, May 10, 2011 at 4:17 PM, John Miller iii <miller3@us.ibm.com> wrote: > Laurie: > > You do not need a stored procedure. The following will work, used the > stores_demo database as an example schema. > > select first 100 * > from customer > where lname >= "Miller" and (case when lname = 'Miller' and fname < "Jane"> then 'f' ELSE 't' END)::boolean > order by lname, fname > > John F. Miller III > STSM, Embedability Architect > miller3@us.ibm.com > 503-578-5645 > IBM Informix Dynamic Server (IDS) > > ids-bounces@iiug.org wrote on 05/10/2011 11:49:05 AM: > > > [image removed] > > > > Re: Slow Query with index [23626] > > > > Laurie Gustin > > > > to: > > > > ids > > > > 05/10/2011 11:55 AM > > > > Sent by: > > > > ids-bounces@iiug.org > > > > Please respond to ids > > > > Thanks for the insight Art! > > > > Still not knowing exactly why this queries performs differently, I took > what > > you said and put it all in a stored procedure that will separate the 'two > > > sides of the union' and only do the second half if needed. It returns a > > sub-second response - no matter what part of the alphabet you are in.. or > how > > many records for a single last name. > > > > Thanks for everyone's help on this!! > > > > Laurie > > > > Laurie Gustin > > Database Administrator > > Dept of Technology Services > > Dept of Public Safety > > lgustin@utah.gov > > 801-965-4410 > > > > >>> "Art Kagel" <art.kagel@gmail.com> 5/10/2011 11:17 AM >>> > > OK, here's the problem. The optimzer is treating the inequality filter > and > > the equality filters as if this were a UNION of two separate queries. So > it > > is seeing: > > > > select first 100> > > > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, > > vo_middle_name, > > > > vo_addr_set_id,vehownindex > > from vehicle_owner > > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') > > > > and ((vo_last_name = 'WADSWORTH' and vo_first_name >= 'RALPH'))) > > UNION > > select first 100> > > > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, > > vo_middle_name, > > > > vo_addr_set_id,vehownindex > > from vehicle_owner > > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') > > > > and ((vo_last_name > 'WADSWORTH'))) > > order by vo_last_name, vo_first_name; > > > > In order to join the two results sets, remove duplicates, and filter for > the > > first 100 rows, the optimizer must collect all of the matching rows from > > both queries and sort the results. I'm betting that 'ANDERSON' is either > > the smallest value in vo_last_name or there are more than 100 rows with > that > > value in the column and the optimizer knows that, so it is shortcutting > the > > query. It may even be eliminating the second part of the UNION or merging > > > the two into a single '<=' comparison if you also eliminated the filter > on > > vo_first_name when you substituted 'ANDERSON'. I don't know because you > did > > not supply the query plan for that version of the query. If you eliminate > > > the FIRST 100 clause, does it run faster for 'ROGER' & 'WADSWORTH'? > > > > Art > > > > Art S. Kagel > > Advanced DataTools (www.advancedatatools.com) > > Blog: http://informix-myview.blogspot.com/ > > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and > > do not reflect on my employer, Advanced DataTools, the IIUG, nor any > other > > organization with which I am associated either explicitly, implicitly, or > by > > inference. Neither do those opinions reflect those of other individuals > > affiliated with any entity with which I am affiliated nor those of the > > entities themselves. > > > > On Tue, May 10, 2011 at 12:32 PM, Laurie Gustin <lgustin@utah.gov> > wrote: > > > > > > Thanks for the suggestions... > > > > > > I changed the index, leaving out middle_name altogether and putting > type at > > > the end. Then ran the query without the index directive... below is the > > > > query > > > plan. Unfortunately, I no longer have access to the old server to > compare > > > the > > > old query plan... > > > > > > QUERY: (OPTIMIZATION TIMESTAMP: 05-10-2011 10:22:31) > > > ------ > > > select > > > first 100 > > > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, > > > vo_addr_set_id,vehownindex > > > from vehicle_owner > > > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and > > > ((vo_last_name = 'WADSWORTH' and vo_first_name >= 'RALPH') or > (vo_last_name > > > > > > > 'WADSWORTH'))) > > > order by vo_last_name, vo_first_name > > > > > > Estimated Cost: 751789 > > > Estimated # of Rows Returned: 481854 > > > Temporary Files Required For: Order By > > > > > > 1) informix.vehicle_owner: INDEX PATH > > > > > > (1) Index Name: informix.idx_vehowner > > > > > > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) > (Serial, > > > fragments: ALL) > > > > > > Lower Index Filter: informix.vehicle_owner.vo_last_name > 'WADSWORTH' > > > > > > Index Key Filters: ((informix.vehicle_owner.vo_owner_type = 'O' OR > > > informix.vehicle_owner.vo_owner_type = 'E' ) ) > > > > > > (2) Index Name: informix.idx_vehowner > > > > > > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) > (Serial, > > > fragments: ALL) > > > > > > Lower Index Filter: (informix.vehicle_owner.vo_last_name = 'WADSWORTH' > AND > > > informix.vehicle_owner.vo_first_name >= 'RALPH' ) > > > > > > Index Key Filters: ((informix.vehicle_owner.vo_owner_type = 'O' OR > > > informix.vehicle_owner.vo_owner_type = 'E' ) ) > > > > > > The query still took over 2 minutes. > > > > > > When I run the query with the last name of ANDERSEN, it takes about 1 > > > second... > > > > > > Thanks > > > Laurie > > > > > > >>> "Art Kagel" <art.kagel@gmail.com> 5/10/2011 9:13 AM >>> > > > Try adding this index and removing the +INDEX() optimizer directive: > > > > > > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner > > > ( vo_last_name asc, > > > vo_first_name asc, > > > vo_owner_type, > > > vo_middle_name asc > > > ) ; > > > > > > If that doesn't work, post the original and new SET EXPLAIN outputs and > > > > we'll take a look. > > > > > > Art > > > > > > Art S. Kagel > > > Advanced DataTools (www.advancedatatools.com) > > > Blog: htt

Thanks John!! This will make things even easier on the developers! and its screamin' fast! I like that. Laurie >>> "John Miller iii" <miller3@us.ibm.com> 5/10/2011 2:17 PM >>> Laurie: You do not need a stored procedure. The following will work, used the stores_demo database as an example schema. select first 100 * from customer where lname >= "Miller" and (case when lname = 'Miller' and fname < "Jane"then 'f' ELSE 't' END)::boolean order by lname, fname John F. Miller III STSM, Embedability Architect miller3@us.ibm.com 503-578-5645 IBM Informix Dynamic Server (IDS) ids-bounces@iiug.org wrote on 05/10/2011 11:49:05 AM: > [image removed] > > Re: Slow Query with index [23626] > > Laurie Gustin > > to: > > ids > > 05/10/2011 11:55 AM > > Sent by: > > ids-bounces@iiug.org > > Please respond to ids > > Thanks for the insight Art! > > Still not knowing exactly why this queries performs differently, I took what > you said and put it all in a stored procedure that will separate the 'two > sides of the union' and only do the second half if needed. It returns a > sub-second response - no matter what part of the alphabet you are in.. or how > many records for a single last name. > > Thanks for everyone's help on this!! > > Laurie > > Laurie Gustin > Database Administrator > Dept of Technology Services > Dept of Public Safety > lgustin@utah.gov > 801-965-4410 > > >>> "Art Kagel" <art.kagel@gmail.com> 5/10/2011 11:17 AM >>> > OK, here's the problem. The optimzer is treating the inequality filter and > the equality filters as if this were a UNION of two separate queries. So it > is seeing: > > select first 100> > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, > vo_middle_name, > > vo_addr_set_id,vehownindex > from vehicle_owner > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') > > and ((vo_last_name = 'WADSWORTH' and vo_first_name >= 'RALPH'))) > UNION > select first 100> > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, > vo_middle_name, > > vo_addr_set_id,vehownindex > from vehicle_owner > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') > > and ((vo_last_name > 'WADSWORTH'))) > order by vo_last_name, vo_first_name; > > In order to join the two results sets, remove duplicates, and filter for the > first 100 rows, the optimizer must collect all of the matching rows from > both queries and sort the results. I'm betting that 'ANDERSON' is either > the smallest value in vo_last_name or there are more than 100 rows with that > value in the column and the optimizer knows that, so it is shortcutting the > query. It may even be eliminating the second part of the UNION or merging > the two into a single '<=' comparison if you also eliminated the filter on > vo_first_name when you substituted 'ANDERSON'. I don't know because you did > not supply the query plan for that version of the query. If you eliminate > the FIRST 100 clause, does it run faster for 'ROGER' & 'WADSWORTH'? > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.com) > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions and > do not reflect on my employer, Advanced DataTools, the IIUG, nor any other > organization with which I am associated either explicitly, implicitly, or by > inference. Neither do those opinions reflect those of other individuals > affiliated with any entity with which I am affiliated nor those of the > entities themselves. > > On Tue, May 10, 2011 at 12:32 PM, Laurie Gustin <lgustin@utah.gov> wrote: > > > Thanks for the suggestions... > > > > I changed the index, leaving out middle_name altogether and putting type at > > the end. Then ran the query without the index directive... below is the > > query > > plan. Unfortunately, I no longer have access to the old server to compare > > the > > old query plan... > > > > QUERY: (OPTIMIZATION TIMESTAMP: 05-10-2011 10:22:31) > > ------ > > select > > first 100 > > vo_veh_id, vo_owner_type, vo_first_name, vo_last_name, vo_middle_name, > > vo_addr_set_id,vehownindex > > from vehicle_owner > > where ((vo_owner_type = 'O' OR vo_owner_type = 'E') and > > ((vo_last_name = 'WADSWORTH' and vo_first_name >= 'RALPH') or (vo_last_name > > > > > 'WADSWORTH'))) > > order by vo_last_name, vo_first_name > > > > Estimated Cost: 751789 > > Estimated # of Rows Returned: 481854 > > Temporary Files Required For: Order By > > > > 1) informix.vehicle_owner: INDEX PATH > > > > (1) Index Name: informix.idx_vehowner > > > > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) (Serial, > > fragments: ALL) > > > > Lower Index Filter: informix.vehicle_owner.vo_last_name > 'WADSWORTH' > > > > Index Key Filters: ((informix.vehicle_owner.vo_owner_type = 'O' OR > > informix.vehicle_owner.vo_owner_type = 'E' ) ) > > > > (2) Index Name: informix.idx_vehowner > > > > Index Keys: vo_last_name vo_first_name vo_owner_type (Key-First) (Serial, > > fragments: ALL) > > > > Lower Index Filter: (informix.vehicle_owner.vo_last_name = 'WADSWORTH' AND > > informix.vehicle_owner.vo_first_name >= 'RALPH' ) > > > > Index Key Filters: ((informix.vehicle_owner.vo_owner_type = 'O' OR > > informix.vehicle_owner.vo_owner_type = 'E' ) ) > > > > The query still took over 2 minutes. > > > > When I run the query with the last name of ANDERSEN, it takes about 1 > > second... > > > > Thanks > > Laurie > > > > >>> "Art Kagel" <art.kagel@gmail.com> 5/10/2011 9:13 AM >>> > > Try adding this index and removing the +INDEX() optimizer directive: > > > > create index 'informix'.idx_vehowner on 'informix'.vehicle_owner > > ( vo_last_name asc, > > vo_first_name asc, > > vo_owner_type, > > vo_middle_name asc > > ) ; > > > > If that doesn't work, post the original and new SET EXPLAIN outputs and > > we'll take a look. > > > > Art > > > > Art S. Kagel > > Advanced DataTools (www.advancedatatools.com) > > Blog: http://informix-myview.blogspot.com/ > > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > > and > > do not reflect on my employer, Advanced DataTools, the IIUG, nor any other > > organization with which I am associated either explicitly, implicitly, or > > by > > inference. Neither do those opinions reflect those of other individuals > > affiliated with any entity with which I am affiliated nor those of the > > entities themselves. > > > > On Tue, May 10, 2011 at 11:00 AM, Laurie Gustin <lgustin@utah.gov> wrote: > > > > > IDS 11.50 FC8X4 > > > Linux > > > > > > I have a query that has been successfully running on an IDS 10.0 for > > quite > > > some time. We recently moved the database to an 11.5 server, and the > > resul