That's why I isolated it down to a standalone example ... There is no other
process looking at that table ... no foreign keys or other things that could
cause those records to be "in use" ... That was the first thing that ran
through my mind when my application was starting to get really slow ...
Also, you'll see from my script that I exit and re-enter psql between each
operation (INSERT, DELETE, VACUUM) so if the transaction wasn't committing,
then the rows wouldn't exist the next time I entered ...
Is there a query I can run to see who is holding those tuples which is
causing VACUUM to leave them in place?
-dave
> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Jeffrey W. Baker
> Sent: Monday, April 08, 2002 2:45 PM
> To: David Esposito
> Cc: Postgres general mailing list
> Subject: Re: [GENERAL] vacuuming not working?
>
>
> On Mon, 2002-04-08 at 10:40, David Esposito wrote:
> > Me again,
> >
> > I have a problem with VACUUM. I searched the list and don't seem to see
> > anyone else reporting this behavior so I'm wondering if i'm
> doing something
> > wrong
>
> > NOTICE: Pages 655: Changed 9, Empty 0; Tup 40000: Vac 0, Keep
> 40000, UnUsed
> ^^^^^^^^^^
>
> The "Keep" number in VACUUM means some transaction can still see those
> rows. Check for long-lived transactions hanging around.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
