Re: Speed while runnning large transactions.

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Greg Smith" <gsmith(at)gregsmith(dot)com>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <jesper(at)krogh(dot)cc>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Speed while runnning large transactions.
Date: 2009-10-02 20:30:14
Message-ID: 4AC61C86020000250002B5D8@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> As of 8.4, the typical case is that an open transaction blocks
> deletion of rows that were deleted since the transaction's current
> *statement* started. So this makes a huge difference if you have
> long-running transactions that consist of a series of not-so-long
> statements. It also means that transactions that sit "idle in
> transaction" are not a hazard for VACUUM anymore --- an idle
> transaction doesn't block deletion of anything.

Surely the original version of a row updated or deleted by the
long-running transaction must be left until the long-running
transaction completes; otherwise, how does ROLLBACK work? (The OP did
mention that there were a large number of updates and deletes being
performed by the long-running transaction....)

-Kevin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2009-10-02 21:38:35 Re: Best suiting OS
Previous Message Justin Pryzby 2009-10-02 19:58:12 dump time increase by 1h with new kernel