Re: Need to run CLUSTER to keep performance - Mailing list pgsql-performance

From Rafael Martinez
Subject Re: Need to run CLUSTER to keep performance
Date
Msg-id 47396527.5090801@usit.uio.no
Whole thread Raw
In response to Re: Need to run CLUSTER to keep performance  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Need to run CLUSTER to keep performance  (Rafael Martinez <r.m.guerrero@usit.uio.no>)
List pgsql-performance
Heikki Linnakangas wrote:
> Rafael Martinez wrote:
>> DETAIL:  83623 dead row versions cannot be removed yet.
>
> Looks like you have a long-running transaction in the background, so
> VACUUM can't remove all dead tuples. I didn't see that in the vacuum
> verbose outputs you sent earlier. Is there any backends in "Idle in
> transaction" state, if you run ps?
>

I don't see any long transaction in progress (<IDLE> in transaction) and
if we run the vacuum jobb manual just after checking this, it still
cannot remove the dead rows.

Any suggestions cause vacuum cannot remove these dead rows?

> In 8.1, CLUSTER will remove those tuples anyway, but it's actually not
> correct.

With other words, .... we have to be very carefull to not run CLUSTER on
a table been modified inside a transaction if we do not want to lose
data? ...

Does this mean that if we run a transaction which update/delete many
rows, run cluster before the transaction is finnish, and then rollback
the transaction after cluster has been executed, all dead rows
updated/deleted  by the transaction can not be rollbacked back because
they are not there anymore?


--
 Rafael Martinez, <r.m.guerrero@usit.uio.no>
 Center for Information Technology Services
 University of Oslo, Norway

 PGP Public Key: http://folk.uio.no/rafael/

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: ERROR: "invalid memory alloc request size" or "unexpected end of data" on large table
Next
From: Rafael Martinez
Date:
Subject: Re: Need to run CLUSTER to keep performance