Jerry Sievers <jerry@xxxxxxxxxxxxxxxx> writes: > What happened was that for a couple minutes the CPU load would > steadily increase and disk activity decrease at the same time. Before > long, one CPU is 100% busy and we let this continue for 2 hours, a > 100x longer than this index usually takes to build. Disk IO dropped > to nothing and remained so. Hm, we were just doing some work in this area a week or two ago, and 8.2 should be materially faster than current releases ... but offhand I don't know why 8.1 would be any worse than earlier versions. Looking in the CVS history shows that the sort logic didn't change at all between 8.0 and 8.1. Are you sure index build on this index really performs differently than it did in 8.0? What platform is this on? > Worse is that the backend that was spinning would not respond to a > cancel nor SIGTERM. Stopping this activity required a -m immediate > shutdown of Postgres. Yeah, we also noticed last week that some of the major loops in btree index build were free of any CHECK_FOR_INTERRUPTS calls :-(. This is fixed for 8.1.4. > If it would be of interest to someone that I truss one of the spinning > processes, I can redo this in an R&D setting and submit the results. truss probably wouldn't show anything interesting; a gprof or oprofile profile could be useful though. regards, tom lane
