From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Markus Bertheau <twanger(at)bluetwanger(dot)de> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: recovery after long delete |
Date: | 2005-04-14 16:34:30 |
Message-ID: | 1505.1113496470@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Markus Bertheau <twanger(at)bluetwanger(dot)de> writes:
> Now if you pull the plug after 2, at startup, pg will go through the
> in-progress txns and mark them as aborted. That's all the recovery in
> this case. All rows are still there. O(1).
Right. (Actually it's O(checkpoint interval), because we have to make
sure that everything we did since the last checkpoint actually got to
disk --- but in principle, there's zero recovery effort.)
> How does oracle do that? Has all this something to do with mvcc? Why
> does it take oracle so long to recover?
Oracle doesn't do MVCC the same way we do. They update rows in place
and put the previous version of a row into an "undo log". If the
transaction aborts, they have to go back through the undo log and put
back the previous version of the row. I'm not real clear on how that
applies to deletions, but I suppose it's the same deal: cost of undoing
a transaction in Oracle is proportional to the number of rows it
changed. There's also the little problem that the space available for
UNDO logs is limited :-(
As against which, they don't have to VACUUM. So it's a tradeoff.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Fradkin | 2005-04-14 16:38:58 | Re: speed of querry? |
Previous Message | Marko Ristola | 2005-04-14 16:26:41 | Re: Foreign key slows down copy/insert |