I read all the stuff above pretty fast so take the following advice
with a grain of salt. Plus brainstorming has both good and bad
ideas. So here goes . . .

1. Most performance issues are due to I/O. Reducing I/O should get
you more speed. For example "INSERT INTO table1 SELECT * FROM table2"
will do 1 read and 1 write in "informix format". But if you pull your
data into a program, you will probably have extra reads, writes plus 2
translations (from informix to ASCII and then back again). Try to
rewrite your program to do the INSERT/SELECT with the appropriate
WHERE clause to break the data up into smaller pieces.

2. Run the inserts in parallel. For example program1 only inserts
into fragment1. Then do the same, in parallel, for the other
fragments. But watch out that you don't overwhelm your CPU's!

3. Do light scans with SET ISOLATION TO DIRTY READ. It will help you
on the SELECT side but not the INSERT side.

4. In C programming I am told that you can define the data as
binary. I am told that can speed it up.

5. In our Informix 10.00.FC4 ONCONFIG we have:

BTSCANNER
num=1,priority=low,threshold=50000,rangesize=10000

6. Upgrade to 11.5 as soon as possible. IBM is bragging that it is
faster than 10.

Are there larger deletes (or updates modifying indexed fields)
performed on this table occasionally? If so, the inserts could be
running on index areas with lots of uncleaned deleted items if btree
cleaning wasn't able to cope yet. See 'onstat -C hot' if some of your
index partitions are on the hot list, with many dirty hits, but still
unlceaned/just being cleaned.

If this should be part of your problem, you could try more btree
scanners and also consider using "alice" mode scanning which should
allow for much quicker btree cleaning.

A simple test for uncleaned indices being in your way would be to see
how performance behaves with newly recreated indices (and no deletes
after).

HTH,
Andreas

Following index might take time for 1B records to make sure your new
insert statement is valid.

create unique index "appdba".application_ref_u01 on
"appdba".application_ref (application_ref_id)
using btree ;
alter table "appdba".application_ref add constraint primary key
(application_ref_id)
constraint "appdba".application_ref_p01 ;