Running 4GL on table that changes a lot

I think this is in the CDI archives, but I haven't found it yet. If memory serves me right, it was discussed on this list some years ago. Some of our programs run batch processes, dropping & creating tables, and then inserting lots of records into them ... BUT, and this is my problem, the program also reads from the tables being inserted into. Because these tables are recreated, no (update) statistics exist on them. But I also can't create them, run update stats and then read from them - the reading and inserting happens at the same time. How do I overcome this problem ? Hope my question is clear enough. Dirk IDS7.31FD3 Solaris 9 Dirk Moolman Database and Unix Administrator MXGROUP "People demand freedom of speech as a compensation for the freedom of thought which they seldom use." sending to informix-list

Dirk Moolman wrote: > I think this is in the CDI archives, but I haven't found it yet. If > memory serves me right, it was discussed on this list some years ago. > > Some of our programs run batch processes, dropping & creating tables, > and then inserting lots of records into them ... BUT, and this is my > problem, the program also reads from the tables being inserted into. > > Because these tables are recreated, no (update) statistics exist on > them. But I also can't create them, run update stats and then read from > them - the reading and inserting happens at the same time. > > How do I overcome this problem ? Hope my question is clear enough. Maintain minimal stats on the table (UPDATE STATISTICS LOW .... DROP DISTRIBUTIONS;). That will force the optimizer to use older less intelligent logic when evaluating the costs of joining to this table which should give acceptable performance in this schenario. This update is cheap to run and you can run it occassionally (say after every 100 or 500 reads)so that the row counts and index depth (pretty much all that LOW keeps) are not too far off. Art S. Kagel > Dirk