Reports vs ESQL vs C-ISAM

Does anybody know the relative speed of Informix Reports in relation to ESQL or C-ISAM. The reason I wish to know is that the system (Infomix 7.20 on Sco Unix 5) is being dragged down by Informix Reports, and we are looking to convert them to their ESQL or C-ISAM equivalent. Additionally, I have been told that Informix only uses one processor of the 4 available, although newer versions support the parallel processors. Would ESQL/C-ISAM work with all 4? Thanks for any help. Regards, Darren Rees

Darren Rees wrote: > > Does anybody know the relative speed of Informix Reports in relation to ESQL > or C-ISAM. > > The reason I wish to know is that the system (Infomix 7.20 on Sco Unix 5) is > being dragged down by Informix Reports, and we are looking to convert them > to their ESQL or C-ISAM equivalent. Did you consider Perl with DBD/DBI ? (See the http://www.iiug.org for DBI::Informix). That's also an (interesting) option. > Additionally, I have been told that Informix only uses one processor of the > 4 available, although newer versions support the parallel processors. Would > ESQL/C-ISAM work with all 4? I don't know about this. Which server are you using ? Using ESQL/C seems a better idea than using C-ISAM. And Perl with DBI::Informix is perhaps a safer choice than ESQL/C.

Darren Rees wrote: > > Does anybody know the relative speed of Informix Reports in relation to ESQL > or C-ISAM. > > The reason I wish to know is that the system (Infomix 7.20 on Sco Unix 5) is > being dragged down by Informix Reports, and we are looking to convert them > to their ESQL or C-ISAM equivalent. Are you sure the SQL is as efficient as it could be?? > > Additionally, I have been told that Informix only uses one processor of the > 4 available, although newer versions support the parallel processors. Would > ESQL/C-ISAM work with all 4? Thats doesn't sound right, Version 7.10 on Sco could use all the processors if required. > > Thanks for any help. > Regards, Darren Rees -- Paul Watson # WF Software Ltd # You are only young once Tel: +44 1436 674729 # but you can be immature Fax: +44 1436 678693 # for ever www.wfsoftware.com #

In article <959102266.24531.0.nnrp-11.c2de0759@news.demon.co.uk>, mrjolly@dadadada.demon.co.uk says... >Does anybody know the relative speed of Informix Reports in relation to ESQL >or C-ISAM. > >The reason I wish to know is that the system (Infomix 7.20 on Sco Unix 5) is >being dragged down by Informix Reports, and we are looking to convert them >to their ESQL or C-ISAM equivalent. There shouldn't be anything intrinsically slower or faster with a given SQL statement; if you strip the SQL statements out of your reports and embed them into an ESQL/C program (or, for that matter, perl with DBD/DBI as someone suggested), you likely wouldn't achieve much improvement unless you have a report that is actually doing serious number crunching or other processing on the data. If it's like most reports that just select data and format the output, I wouldn't expect much of a performance benefit, if any. Try running the SQL from dbaccess with SET EXPLAIN ON and see if any of the warning signs of bad SQL are present (sequential searches, high expected costs, etc.) -- William Harris william@carsinfo.com

William Harris <william@carsinfo.com> wrote in message news:8gesdt$s7o$1@malgudi.oar.net... > In article <959102266.24531.0.nnrp-11.c2de0759@news.demon.co.uk>, > mrjolly@dadadada.demon.co.uk says... > >Does anybody know the relative speed of Informix Reports in relation to ESQL > >or C-ISAM. > > > >The reason I wish to know is that the system (Infomix 7.20 on Sco Unix 5) is > >being dragged down by Informix Reports, and we are looking to convert them > >to their ESQL or C-ISAM equivalent. > > There shouldn't be anything intrinsically slower or faster with a given SQL > statement; if you strip the SQL statements out of your reports and embed them > into an ESQL/C program (or, for that matter, perl with DBD/DBI as someone > suggested), you likely wouldn't achieve much improvement unless you have a > report that is actually doing serious number crunching or other processing on > the data. If it's like most reports that just select data and format the > output, I wouldn't expect much of a performance benefit, if any. I should've mentioned that the reports are doing many SELECT statements (usually around 10), processing a lot of data (containing 100000's rows) BEFORE getting to the actual formatting of the report data. The reason that the SQL is embedded in the reports is because the reports need to be run by many people at the same time, passing different parameters, and producing dfferent results. > > Try running the SQL from dbaccess with SET EXPLAIN ON and see if any of the > warning signs of bad SQL are present (sequential searches, high expected > costs, etc.) The queries are based upon indexes as far as is possible, with few subqueries, although I will try your suggestion. Thanks.