1.) OK. We have narrowed it down.
We did a few (like 5 to 8 times) vacuum analyze <tablename> (no full), the pg_statistics relfilenode grew. There was no database operation when we did this, no other client connections except the one that does the vacuum.
If we do plain simple "vacuum <tablename>" (again no full), we see pg_statistics_relid_att_index relfilenode grew instead of pg_statistics.
So, overtime, these files will grow if we do vacuum.
Are these expected ?
The question now is, if we are not doing anything to the database, why would they grow after a few vacuums ?
2.) The other problem we have with
DETAIL: 101802 dead row versions cannot be removed yet.
DETAIL: 110900 dead row versions cannot be removed yet.
DETAIL: 753064 dead row versions cannot be removed yet.
DETAIL: 765328 dead row versions cannot be removed yet.
We will collect more data and see what we can get from the the process. Offhand, the process is connecting to the database through ODBC and we don't use any BEGIN in our updates, just doing plain UPDATE repeatedly with different keys randomly. The database is defaulted to autocommit=true in postgresql.conf.
Thanks.
Gan
At 5:25 pm -0400 2003/10/20, Tom Lane wrote:
Seum-Lim Gan <[EMAIL PROTECTED]> writes:We tried one more thing: with the table not being updated at all and we did vacuum. Each time a vacuum is done, the index file becomes bigger.
It is not possible for plain vacuum to make the index bigger.
VACUUM FULL possibly could make the index bigger, since it has to transiently create duplicate index entries for every row it moves.
If you want any really useful comments on your situation, you're going to have to offer considerably more detail than you have done so far --- preferably, a test case that lets someone else reproduce your results. So far, all we can do is guess on the basis of very incomplete information. When you aren't even bothering to mention whether a vacuum is FULL or not, I have to wonder whether I have any realistic picture of what's going on.
regards, tom lane
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
-- +--------------------------------------------------------+ | Seum-Lim GAN email : [EMAIL PROTECTED] | | Lucent Technologies | | 2000 N. Naperville Road, 6B-403F tel : (630)-713-6665 | | Naperville, IL 60566, USA. fax : (630)-713-7272 | | web : http://inuweb.ih.lucent.com/~slgan | +--------------------------------------------------------+
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
