Re: Vacuum time degrading

On 3/2/05 3:51 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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