From: | Ravi Krishna <sravikrishna3(at)gmail(dot)com> |
---|---|
To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PG and undo logging |
Date: | 2015-05-24 13:15:11 |
Message-ID: | CACER=P0wYhmX89XytWQDp=t+4eyXKQtZZuJrvr8z8JHi-LNf8A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, May 23, 2015 at 10:12 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> Ever run an insert with 1M rows, and roll it back in postgresql and
> compare that to oracle. Time the rollback in both. That should give
> you an idea of how differently the two dbs operate.
>
> A rollback in postgres is immediate because it's already "rolled back"
> so to speak. NONE of it's in the main data store yet, it's all in the
> transaction log waiting.
>
> Oracle spends it's time and effort creating an "undo" log because it
> commits every so often, whether or not you've committed your
> transaction.
>
> PostgreSQL doesn't. The whole transaction exists in the transaction
> log (called xlog dir in pg lingo.)
>
> When you roll back a pg transaction it literally requires almost no
> work. Mark the transaction as aborted etc and get on with life.
> Transaction logs get cleaned up as usual in the background and we go
> on our way.
>
> This means that Oracle uses space for rollback, while postgres uses
> space for "roll forward" (aka the transaction logs) so to speak.
Thanks for the detailed explanation. The explanation makes me wonder
that PG must do more work at commit time, right?
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Elphick | 2015-05-24 13:16:16 | Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY" |
Previous Message | Oliver Elphick | 2015-05-24 12:52:47 | Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY" |