Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Illogical performance increase? - Update Stats

Status
Not open for further replies.

schu

MIS
Jun 21, 2001
188
0
0
HK
One of our development team found something strange, whilst trying to tune a large month end job.

The results boils down to:

Test 1
1. Drop/create working table (say abc_wk)
2. Update stats high for all tables involved in the job except abc_wk.
3. Run job to populate abc_wk (110000 recs)
4. Run update stats high on abc_wk after population
5. Run rest of the job
total about 9 hours to complete

Test 2
1. Drop/create working table (say abc_wk)
2. Update stats high for all tables involved in the job INCLUDING abc_wk.
3. Run job to populate abc_wk (110000 recs)
4. Run update stats high on abc_wk after population
5. Run rest of the job
total about 3.5 hours to complete

A difference of 5 hours.

The server was dedicated for the job, not other tasks such as backups were running on the development machine.

I first thought that Informix may not be clearing the distributions after the drop/create but a little test proves this is not the case.

How does running update statistics high on an empty table improve performance. Unfortunately I do not have much more details of the tests.

BTW, we are using IDS 7.31 UD1 on Solaris 7, E3500 with 4CPU 2G RAM

The developers ask me if this method can be used to increase performance of other jobs, before they go and alter other jobs. I could not give them an answer.

It would be greatly appreciated if anyone has an explaination or have a similar set up which they can test and see if they get performance increase using the same method.

 
usually empty tables are populated with constraints disabled (set constraint "name disabled/enabled).
(in first case distributions and other stats assumes you still have old large table (it is fixed with MEDIUM DISTRIBUTIONS ONLY faster)
you can update statistics high for stored procedure which includes great month-end job (much faster).
It is slow anyway - have a look at older performance recommendations.
You can use set explain (coder should know of it) on smaller rowsets to optimize your processing faster than in 12 hours per test
 
and what about table extent sizes- usually larger tables load at nearly disk IO speed
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top