This begs the real question. What is a fast fetch time?
Time to fetch the first row?
OR
Time to fetch all rows?
By default the Informix Optimize assumes you want the fastest time to fetch
all
rows. If you are only measuring the time to fetch the first row then this
could
be an inconsistency in the testing methodology.
If the optimize changed the query plan to use a blocking style operator,
like
sort, hash join, instead of an inline operator (such as nest loop join)
then the time to receive the first row will be slower, but the
time to process all rows of the query should be faster.
John F. Miller III
STSM, Lead Architect
miller3@us.ibm.com
503-747-1366
IBM Informix Dynamic Server (IDS)
ids-bounces@iiug.org wrote on 05/17/2015 10:20:43 AM:
> From: "JAVIER PEREZ ARENAL"<jperez@uniovi.es>
> To: ids@iiug.org
> Date: 05/17/2015 10:21 AM
> Subject: RE: Fetch time on 12.10FC4 [35109]
> Sent by: ids-bounces@iiug.org
>
> Thanks for your answers, Alberto and Art! ...
>
> But the problem is not on the statistics. To make a more exhaustive test
I=
> make two fresh installs on the same machine (Dell PowerEdge R630 with two
=
> Intel Xeon E5-2680 v3, 32 GB RAM, two RAID-1 over 15k 6Gbps SAS HDD and
one=
> 1Gbps Broadcom NIC where the RDBMS is listening). I have two IDS
instances=
> , one in 11.70.FC8 version and the other in 12.10.FC4 version. The
onconfig=
> on two instances are equal (except for the new parameters in v12.10).
Afte=
> r instance inicialization, I import the same database in them and, using
Ar=
> t's utilities (great work, Art!!!), I execute dostats to give statistics
up=
> to date. This is a non production system and I can assure there's no more
=
> concurrent connections.
>
> Well... after this work, the results of one SQL execution (from AGS
Server=
> Studio 9.x) are these:
>
> ** IDS 11.70: Time of execution: 00:00:00,01 / Time for fetching data:
00:=
> 00:11,454
>
> ** IDS 12.10: Time of execution: 00:00:00,01 / Time for fetching data:
00:=
> 00:22,912
>
> As you can see, the fetch time in 12.10 instance doubles the same time in
=
> 11.70... This is amazing to me. We have Informix for many years (since
v7.3=
> 1), and I never see nothing like this (I made some upgrades before this,
in=
> cluding major releases).
>
> I forget to mention the OS version: Red Hat Enterprise v7 x64.
> =09
>
> Any help would be appreciated.
>
> Best regards.
>
> --
> Javier Perez Arenal - jperez@uniovi.es
> Jefe del Area T=E9cnica de Inform=E1tica y Comunicaciones=20
> Vicerrectorado de Campus, Inform=E1tica e Infraestructuras
> Universidad de Oviedo=20
> Edificio Severo Ochoa=20
> C/ Fernando Bongera s/n, Campus del Cristo
> 33006 - Oviedo, Asturias
>
> -----Mensaje original-----
> De: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] En nombre de Art
Kag=
> el
> Enviado el: s=E1bado, 16 de mayo de 2015 0:56
> Para: ids@iiug.org
> Asunto: Re: Fetch time on 12.10FC4 [35107]
>
> Alberto makes a good point. Whenever you perform an in-place upgrade even
b=
> etween minor versions, you must drop all distributions and rebuilld
them.=20
> My dostats utility has options to do this for you:=20
> --drop-distributions and --clean-distributions=20
>
> If you are updating the entire database with a single dostats run, you
can =
> use either (--drop-distributions is a bit faster), but if you are running
s=
> everal copies of dostats on a database, such as through the drive_dostats
s=
> cript, then you must use --clean-distributions instead.=20
>
> If you are coding a script yourself, then run:=20
>
> update statistics log drop distributions only;=20
>
> first then recreate your distributions as usual. Do not rely on AUS to
fix =
> this up for you.=20
>
> Art=20
>
> Art S. Kagel, President and Principal Consultant ASK Database Management
ww=
> w.askdbmgt.com=20
>
> Blog: http://informix-myview.blogspot.com/=20
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
an=
> d do not reflect on the IIUG, nor any other organization with which I am
as=
> sociated either explicitly, implicitly, or by inference. Neither do those
o=
> pinions reflect those of other individuals affiliated with any entity
with =
> which I am affiliated nor those of the entities themselves.=20
>
> On Fri, May 15, 2015 at 5:52 PM, Alberto Romeu Pessonio Filho <
albasic@gma=
> il.com> wrote:=20
>
> > Hi Javier!=20
> >=20
> > Did you rebuild the statistics of all databases from your instance=20
> > after the upgrade?
> > This situation (differences between fetch time and exec time) used
to=20
> > happen when table's statistics are not accurate.
> >=20
> > Regards,
> > Alberto Pessonio
> >=20
> > 2015-05-15 18:35 GMT-03:00 JAVIER PEREZ ARENAL <jperez@uniovi.es>:=20
> >=20
> > > Hi
> > >=20
> > > I made an in-place upgrade of some pre-production instances from=20
> > > 11.70 to 12.10FC4WE.
> > >=20
> > > Since these upgrades, the "fetch time" of some sql statements are=20
> > > significatively more slow while the exec time is the same,
comparing=20
> > > to
> > the
> > > old versi=F3n ones.=20
> > >=20
> > > In the upgrade process I do not touch any network parameter:=20
> > >=20
> > > Sqlhosts:=20
> > > clusterifx2 onsoctcp clusterifx2 ids_service
> > >=20
> > > Onconfig:=20
> > >=20
> > > NETTYPE soctcp,4,150,NET
> > > LISTEN_TIMEOUT 10
> > > MAX_INCOMPLETE_CONNECTIONS 1024
> > > FASTPOLL 1
> > > NUMFDSERVERS 4
> > > NS_CACHE host=3D900,service=3D900,user=3D900,group=3D900
> > >=20
> > > Could you help me with this?=20
> > >=20
> > > Thanks in advance!=20
> > >=20
> > > --
> > > Javier Perez Arenal - jperez@uniovi.es<mailto:jperez@uniovi.es>
> > > Jefe del Area T=E9cnica de Inform=E1tica y Comunicaciones
Vicerrectorad=
> o=20
> > > de Campus, Inform=E1tica e Infraestructuras Universidad de Oviedo=20
> > > Edificio Severo Ochoa C/ Fernando Bongera s/n, Campus del Cristo
> > > 33006 - Oviedo, Asturias
> > >=20
> > > --_000_DB5PR04MB092091D6EAE330549D99B9A7D2C70DB5PR04MB0920eurp_
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
> >=20
>
***************************************************************************=
> ****=20
> > > Forum Note: Use "Reply" to post a response in the discussion
forum.=20
> > >=20
> > >=20
> >=20
> > --001a11345dd40fd3ec051625dbe0
> >=20
> >=20
> >=20
> >=20
>
***************************************************************************=
> ****=20
> > =20
> >=20
> >=20
>
> --bcaec5196941166c82051626beb9=20
>
>
***************************************************************************=
> ****
> =20
>
>
>
>
>
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [35129]
*******************************************************************************
Time to fetch the first row?
OR
Time to fetch all rows?
By default the Informix Optimize assumes you want the fastest time to fetch
all
rows. If you are only measuring the time to fetch the first row then this
could
be an inconsistency in the testing methodology.
If the optimize changed the query plan to use a blocking style operator,
like
sort, hash join, instead of an inline operator (such as nest loop join)
then the time to receive the first row will be slower, but the
time to process all rows of the query should be faster.
John F. Miller III
STSM, Lead Architect
miller3@us.ibm.com
503-747-1366
IBM Informix Dynamic Server (IDS)
ids-bounces@iiug.org wrote on 05/17/2015 10:20:43 AM:
> From: "JAVIER PEREZ ARENAL"<jperez@uniovi.es>
> To: ids@iiug.org
> Date: 05/17/2015 10:21 AM
> Subject: RE: Fetch time on 12.10FC4 [35109]
> Sent by: ids-bounces@iiug.org
>
> Thanks for your answers, Alberto and Art! ...
>
> But the problem is not on the statistics. To make a more exhaustive test
I=
> make two fresh installs on the same machine (Dell PowerEdge R630 with two
=
> Intel Xeon E5-2680 v3, 32 GB RAM, two RAID-1 over 15k 6Gbps SAS HDD and
one=
> 1Gbps Broadcom NIC where the RDBMS is listening). I have two IDS
instances=
> , one in 11.70.FC8 version and the other in 12.10.FC4 version. The
onconfig=
> on two instances are equal (except for the new parameters in v12.10).
Afte=
> r instance inicialization, I import the same database in them and, using
Ar=
> t's utilities (great work, Art!!!), I execute dostats to give statistics
up=
> to date. This is a non production system and I can assure there's no more
=
> concurrent connections.
>
> Well... after this work, the results of one SQL execution (from AGS
Server=
> Studio 9.x) are these:
>
> ** IDS 11.70: Time of execution: 00:00:00,01 / Time for fetching data:
00:=
> 00:11,454
>
> ** IDS 12.10: Time of execution: 00:00:00,01 / Time for fetching data:
00:=
> 00:22,912
>
> As you can see, the fetch time in 12.10 instance doubles the same time in
=
> 11.70... This is amazing to me. We have Informix for many years (since
v7.3=
> 1), and I never see nothing like this (I made some upgrades before this,
in=
> cluding major releases).
>
> I forget to mention the OS version: Red Hat Enterprise v7 x64.
> =09
>
> Any help would be appreciated.
>
> Best regards.
>
> --
> Javier Perez Arenal - jperez@uniovi.es
> Jefe del Area T=E9cnica de Inform=E1tica y Comunicaciones=20
> Vicerrectorado de Campus, Inform=E1tica e Infraestructuras
> Universidad de Oviedo=20
> Edificio Severo Ochoa=20
> C/ Fernando Bongera s/n, Campus del Cristo
> 33006 - Oviedo, Asturias
>
> -----Mensaje original-----
> De: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] En nombre de Art
Kag=
> el
> Enviado el: s=E1bado, 16 de mayo de 2015 0:56
> Para: ids@iiug.org
> Asunto: Re: Fetch time on 12.10FC4 [35107]
>
> Alberto makes a good point. Whenever you perform an in-place upgrade even
b=
> etween minor versions, you must drop all distributions and rebuilld
them.=20
> My dostats utility has options to do this for you:=20
> --drop-distributions and --clean-distributions=20
>
> If you are updating the entire database with a single dostats run, you
can =
> use either (--drop-distributions is a bit faster), but if you are running
s=
> everal copies of dostats on a database, such as through the drive_dostats
s=
> cript, then you must use --clean-distributions instead.=20
>
> If you are coding a script yourself, then run:=20
>
> update statistics log drop distributions only;=20
>
> first then recreate your distributions as usual. Do not rely on AUS to
fix =
> this up for you.=20
>
> Art=20
>
> Art S. Kagel, President and Principal Consultant ASK Database Management
ww=
> w.askdbmgt.com=20
>
> Blog: http://informix-myview.blogspot.com/=20
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
an=
> d do not reflect on the IIUG, nor any other organization with which I am
as=
> sociated either explicitly, implicitly, or by inference. Neither do those
o=
> pinions reflect those of other individuals affiliated with any entity
with =
> which I am affiliated nor those of the entities themselves.=20
>
> On Fri, May 15, 2015 at 5:52 PM, Alberto Romeu Pessonio Filho <
albasic@gma=
> il.com> wrote:=20
>
> > Hi Javier!=20
> >=20
> > Did you rebuild the statistics of all databases from your instance=20
> > after the upgrade?
> > This situation (differences between fetch time and exec time) used
to=20
> > happen when table's statistics are not accurate.
> >=20
> > Regards,
> > Alberto Pessonio
> >=20
> > 2015-05-15 18:35 GMT-03:00 JAVIER PEREZ ARENAL <jperez@uniovi.es>:=20
> >=20
> > > Hi
> > >=20
> > > I made an in-place upgrade of some pre-production instances from=20
> > > 11.70 to 12.10FC4WE.
> > >=20
> > > Since these upgrades, the "fetch time" of some sql statements are=20
> > > significatively more slow while the exec time is the same,
comparing=20
> > > to
> > the
> > > old versi=F3n ones.=20
> > >=20
> > > In the upgrade process I do not touch any network parameter:=20
> > >=20
> > > Sqlhosts:=20
> > > clusterifx2 onsoctcp clusterifx2 ids_service
> > >=20
> > > Onconfig:=20
> > >=20
> > > NETTYPE soctcp,4,150,NET
> > > LISTEN_TIMEOUT 10
> > > MAX_INCOMPLETE_CONNECTIONS 1024
> > > FASTPOLL 1
> > > NUMFDSERVERS 4
> > > NS_CACHE host=3D900,service=3D900,user=3D900,group=3D900
> > >=20
> > > Could you help me with this?=20
> > >=20
> > > Thanks in advance!=20
> > >=20
> > > --
> > > Javier Perez Arenal - jperez@uniovi.es<mailto:jperez@uniovi.es>
> > > Jefe del Area T=E9cnica de Inform=E1tica y Comunicaciones
Vicerrectorad=
> o=20
> > > de Campus, Inform=E1tica e Infraestructuras Universidad de Oviedo=20
> > > Edificio Severo Ochoa C/ Fernando Bongera s/n, Campus del Cristo
> > > 33006 - Oviedo, Asturias
> > >=20
> > > --_000_DB5PR04MB092091D6EAE330549D99B9A7D2C70DB5PR04MB0920eurp_
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
> >=20
>
***************************************************************************=
> ****=20
> > > Forum Note: Use "Reply" to post a response in the discussion
forum.=20
> > >=20
> > >=20
> >=20
> > --001a11345dd40fd3ec051625dbe0
> >=20
> >=20
> >=20
> >=20
>
***************************************************************************=
> ****=20
> > =20
> >=20
> >=20
>
> --bcaec5196941166c82051626beb9=20
>
>
***************************************************************************=
> ****
> =20
>
>
>
>
>
*******************************************************************************
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [35129]
*******************************************************************************