Index build speedup -- part2

I've taken the ideas that you've given and haven't had much success (. . . yet), but I'd like to try one more thing before I drop this issue (until next year). I've heard that, sometimes, sorting to disk may be faster than sorting to temp dbspace. I'm familiar with the PSORT_DBTEMP environment variable, which overrides any DBSPACETEMP onconfig variable setting. When I set and export it, however, I don't see any disk activity, or any sort files created on the filesystem at all. Am I missing something again? -- John Carlson Informix DBA WHSmith USA #include std_disclaimer.h /* These are my opinions, not my company's opinion */

It may just be that the engine is able to keep everything in memory. Oh, do you have PSORT_NPROCS set and exported? That var is the trigger to enable the PSORT external sort code track. Set it to about 2x NUMCPUVPS more if your CPUS are very fast. The manual says values over 10 are noop but my testing shows increased performance for me up to PSORT_NPROCS=40 with 24 CPU VPS on 32 processors. YMMV Art S. Kagel "Carlson@WHSmith" wrote: > > I've taken the ideas that you've given and haven't had much success (. . > . yet), but I'd like to try one more thing before I drop this issue > (until next year). > > I've heard that, sometimes, sorting to disk may be faster than sorting > to temp dbspace. I'm familiar with the PSORT_DBTEMP environment > variable, which overrides any DBSPACETEMP onconfig variable setting. > When I set and export it, however, I don't see any disk activity, or any > sort files created on the filesystem at all. Am I missing something > again? > > -- > John Carlson > Informix DBA > WHSmith USA > > #include std_disclaimer.h /* These are my opinions, not my company's > opinion */

In article <38596907.7DD5A478@bloomberg.net>, Art S. Kagel <kagel@bloomberg.net> writes >It may just be that the engine is able to keep everything in memory. > >Oh, do you have PSORT_NPROCS set and exported? That var is the trigger to >enable the PSORT external sort code track. Set it to about 2x NUMCPUVPS >more if your CPUS are very fast. The manual says values over 10 are noop >but my testing shows increased performance for me up to PSORT_NPROCS=40 with >24 CPU VPS on 32 processors. YMMV > >Art S. Kagel > Tonight I tried export PSORT_NPROCS=8 export PDQPRIORITY=100 on a 2 processor Sun E170 with 768Mb RAM and 2 CPU VPS. Even with PSORT_PROCS=8 onstat -u did not show more than 4 threads for my session?? Still it was faster than PSORT_PROCS=4. >"Carlson@WHSmith" wrote: >> >> I've taken the ideas that you've given and haven't had much success (. . >> . yet), but I'd like to try one more thing before I drop this issue >> (until next year). >> >> I've heard that, sometimes, sorting to disk may be faster than sorting >> to temp dbspace. I'm familiar with the PSORT_DBTEMP environment >> variable, which overrides any DBSPACETEMP onconfig variable setting. >> When I set and export it, however, I don't see any disk activity, or any >> sort files created on the filesystem at all. Am I missing something >> again? >> >> -- >> John Carlson >> Informix DBA >> WHSmith USA >> >> #include std_disclaimer.h /* These are my opinions, not my company's >> opinion */ -- David Williams

David Williams wrote: > > Tonight I tried > > export PSORT_NPROCS=8 > export PDQPRIORITY=100 > > on a 2 processor Sun E170 with 768Mb RAM and 2 CPU VPS. > > > Even with PSORT_PROCS=8 onstat -u did not show more than 4 > threads for my session?? Still it was faster than PSORT_PROCS=4. > The most time savings I've received from a 1 1/4 hr index build was 7 minutes. I'll log these variable combinations, reset my testing environment, and try again after Y2K. Either I'm missing something, or my system is as tight as I can get it. Oh, bother . . . . -- John Carlson Informix DBA WHSmith USA #include std_disclaimer.h /* These are my opinions, not my company's opinion */