Re: PG and undo logging - Mailing list pgsql-general

From Ravi Krishna
Subject Re: PG and undo logging
Date
Msg-id CACER=P0wYhmX89XytWQDp=t+4eyXKQtZZuJrvr8z8JHi-LNf8A@mail.gmail.com
Whole thread Raw
In response to Re: PG and undo logging  (Scott Marlowe <scott.marlowe@gmail.com>)
Responses Re: PG and undo logging
List pgsql-general
On Sat, May 23, 2015 at 10:12 PM, Scott Marlowe <scott.marlowe@gmail.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?


pgsql-general by date:

Previous
From: Arup Rakshit
Date:
Subject: Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"
Next
From: Oliver Elphick
Date:
Subject: Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"