From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Greg Smith" <gsmith(at)gregsmith(dot)com>, jesper(at)krogh(dot)cc, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Speed while runnning large transactions. |
Date: | 2009-10-02 22:01:05 |
Message-ID: | 15124.1254520865@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> 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.
[ BTW, of course that should have read "blocks removal of" ... ]
> 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?
Right. What I was talking about was the impact of a long-running
transaction on the removal of rows outdated by *other* transactions.
The people who hollered loudest about this seemed to often have
long-running read-only transactions in parallel with lots of short
read-write transactions. That's the pattern that 8.4 can help with
anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2009-10-03 01:48:08 | dump time increase by 1h with new kernel |
Previous Message | Dimitri Fontaine | 2009-10-02 21:58:15 | Re: Best suiting OS |