On 3/2/05 3:51 PM, "Tom Lane" <tgl@xxxxxxxxxxxxx> wrote: > I was going to suggest > REINDEXing those indexes to see if that cuts the vacuum time at all. The problem with that is it takes a very long time. I've got a couple of things to try yet on the kswapd problem. If that doesn't work, maybe I can rebuild one of the indexes and see how much that one improves. I wasn't aware that the indexes were scanned non-sequentially. The under one hour time was probably shortly after a full reload. Any chance of change that behavior to scan in physical storage order? The index from the largest table that has: CPU 216.15s/18.13u sec elapsed 2110.84 sec. is inserted in sequential order. The index CPU 518.88s/25.17u sec elapsed 10825.33 sec. has records inserted in essentially a random order, and is also something like twice as large (key size). We're going to try to test the 2.4.29 kernel tomorrow. Wes ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@xxxxxxxxxxxxxx
