> Yeah, this is proof that what it was doing is the same as what we saw in > Jeff's backtrace, ie loading up the system catalog relcache entries the > hard way via seqscans on the core catalogs. So the question to be > answered is why that's suddenly a big performance bottleneck. It's not > a cheap operation of course (that's why we cache the results ;-)) but > it shouldn't take minutes either. And, because they are seqscans, it > doesn't seem like messed-up indexes should matter.
FWIW, this appeared to be an all-or-nothing event: either every new backend was suffering through this, or none were. They all seemed to clear up at the same time as well. > The theory I have in mind about Jeff's case is that it was basically an > I/O storm, but it's not clear whether the same explanation works for > your case. There may be some other contributing factor that we haven't > identified yet. Let me know if you think of anything particular I can test while it is happening again. I'll try to arrange a (netapp) snapshot the next time it happens as well (this system is too busy and too large to do anything else). -- Greg Sabino Mullane g...@endpoint.com End Point Corporation PGP Key: 0x14964AC8
pgpYJDovfAM7L.pgp
Description: PGP signature
