From: | Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Need to run CLUSTER to keep performance |
Date: | 2007-11-13 08:49:43 |
Message-ID: | 47396527.5090801@usit.uio.no |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
Center for Information Technology Services
University of Oslo, Norway
PGP Public Key: http://folk.uio.no/rafael/
From | Date | Subject | |
---|---|---|---|
Next Message | Rafael Martinez | 2007-11-13 09:03:19 | Re: Need to run CLUSTER to keep performance |
Previous Message | Tom Lane | 2007-11-12 22:54:22 | Re: ERROR: "invalid memory alloc request size" or "unexpected end of data" on large table |