"Steven M. Wheeler" <swheeler@sabre.com> writes:
> I believe that 6.5.2 and a little space reclamation in my DB directory may
> have taken care of the vacuum problem. The last vacuum ran in about 10
> minutes on an already vacuumed DB.
Ah, that's more like it...
> 1) With 6.5.2 should I still drop the indexes prior to running vacuum?
Probably, but I'm not sure. Try it both ways and see.
> 2) Is there a command/script that will cleanup the temp files and previous
> table files in the DB directory. The reason I ask: I now have 3 copies of
> my currnt table file (currnt, currnt.1, currnt.2) for a total usage of
> about 3GB. Since it appears that currnt.2 is the one being accessed, can I
> safely delete currnt & currnt.1?
NO NO NO NO NO!!!!
Files named like that are NOT temp files!! What they are are segments
of a large table. We segment big tables into gigabyte-sized chunks
to avoid problems on systems that have an int32-related limit on the
size of individual files (which is most Unixes these days, I think).
If you see anything named like pg_tempNNN.NNN, then that really is
a temp file, and if it's not got a very recent mod time then it's
probably left over from a crashed backend. Old temp files should be
safe to get rid of. (IIRC, one of the components of the name is the
PID of the creating backend, so you can check to be sure that the
backend is no longer around if you want to be doubly sure.)
regards, tom lane
