Re: [GENERAL] VACUUM FULL performance issues with pg_largeobject table

2010-01-25 Thread PG User 2010
Hi Tom, Unfortunately, I've tried your advice, and I think that we're still in a CPU-bound situation even after following the re-indexing and re-vacuuming. Fortunately, though, I've just learned about a poor-man's profiler under Linux named pstack, and it's telling me that the vacuum process is s

Re: [GENERAL] VACUUM FULL performance issues with pg_largeobject table

2010-01-22 Thread PG User 2010
Hi Tom, As always, your insight is VERY helpful. We'll try your suggestions and see if that helps things out... Thanks! Sam On Fri, Jan 22, 2010 at 4:01 PM, Tom Lane wrote: > PG User 2010 writes: > > 1) is there any easy way to fiddle with the vacuum process so that it is > not > > CPU boun

Re: [GENERAL] VACUUM FULL performance issues with pg_largeobject table

2010-01-22 Thread Tom Lane
PG User 2010 writes: > 1) is there any easy way to fiddle with the vacuum process so that it is not > CPU bound and doing very little I/O? Why would vacuum full be CPU bound > anyway??? The only part of VAC FULL that seems like it could be CPU-bound is index cleanup. If the table is sufficientl

[GENERAL] VACUUM FULL performance issues with pg_largeobject table

2010-01-22 Thread PG User 2010
Hi there, I originally posted these questions to the pgsql-performance mailing list, but due to lack of response, I think that these may be more general in nature--so I'm re-posting them here. Apologies for the cross-posting ahead of time. We are having real issues trying to reclaim dead blob sp