Re: index file bloating still in 7.4 ?

Hi Tom,

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 <slgan(at)lucent(dot)com> 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 : slgan(at)lucent(dot)com |
| 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 |
+--------------------------------------------------------+