Re: [ADMIN] ever growing pkey files

2001-08-15 Thread matthew . copeland
Well, I reindexed on 7.0.3, and that worked. I also upgraded, and that worked with my code also, so ignore the not working comment. Thanks for the help, Matthew M. Copeland On Tue, 14 Aug 2001 [EMAIL PROTECTED] wrote: > > Yeah, VACUUM doesn't shrink indexes presently (it's on the TODO > >

Re: [ADMIN] ever growing pkey files

2001-08-14 Thread matthew . copeland
> Yeah, VACUUM doesn't shrink indexes presently (it's on the TODO > list...). > > > PostgreSQL version 7.0.3 running under Linux. > > You could try REINDEX to rebuild the indexes, but I'd recommend updating > to 7.1.2 (or soon, 7.1.3) first. I don't recall whether REINDEX is > available/trustwo

Re: [ADMIN] ever growing pkey files

2001-08-14 Thread Tom Lane
[EMAIL PROTECTED] writes: > I tried switching > to PostgreSQL 7.1 when it first came out, but it now handles ansynchronous > notification differently to the point where my old code doesn't work > anymore. Uh ... what? I don't recall that we changed NOTIFY behavior in 7.1. There's certainly no o

Re: [ADMIN] ever growing pkey files

2001-08-14 Thread Tom Lane
[EMAIL PROTECTED] writes: > I have a database that has two tables. One of the tables gets changed > very often. (like every 5 minutes). The values that where in the table > are replaced with a new set of values with new unique keys. Now, I vacuum > these tables fairly often, but the pkey files

[ADMIN] ever growing pkey files

2001-08-14 Thread matthew . copeland
I have a database that has two tables. One of the tables gets changed very often. (like every 5 minutes). The values that where in the table are replaced with a new set of values with new unique keys. Now, I vacuum these tables fairly often, but the pkey files for these tables never seem to g