Re: [PERFORM] Speed while runnning large transactions.

2009-10-05 Thread Greg Smith
On Fri, 2 Oct 2009, Tom Lane wrote: 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. Which makes sense if you think about it. Long-running read-only reports are quite common in DBA lan

Re: [PERFORM] Speed while runnning large transactions.

2009-10-02 Thread Tom Lane
"Kevin Grittner" writes: > Tom Lane 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 ver

Re: [PERFORM] Speed while runnning large transactions.

2009-10-02 Thread Kevin Grittner
Tom Lane 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 > stateme

Re: [PERFORM] Speed while runnning large transactions.

2009-10-01 Thread Tom Lane
Greg Smith writes: > 2) Test if an upgrade to PG 8.4 improves your situation. There is some > new code in that version (labeled in the release notes as "Track > transaction snapshots more carefully") that has improved problems in this > area quite a bit for me. There's a bit more detail about

Re: [PERFORM] Speed while runnning large transactions.

2009-10-01 Thread Greg Smith
On Thu, 24 Sep 2009, jes...@krogh.cc wrote: I have a transaction running at the database for around 20 hours .. still isn't done. But during the last hours it has come to the point where it really hurts performance of "other queries". Open transactions grab an internal resource named a snapsho

Re: [PERFORM] Speed while runnning large transactions.

2009-09-29 Thread Robert Haas
2009/9/24 : >> On Thu, Sep 24, 2009 at 9:27 AM, wrote: >> >>> Hi. >>> >>> I have a transaction running at the database for around 20 hours .. >>> still >>> isn't done. But during the last hours it has come to the point where it >>> really hurts performance of "other queries". >>> >>> Given pg_sta

Re: [PERFORM] Speed while runnning large transactions.

2009-09-24 Thread jesper
> On Thu, Sep 24, 2009 at 9:27 AM, wrote: > >> Hi. >> >> I have a transaction running at the database for around 20 hours .. >> still >> isn't done. But during the last hours it has come to the point where it >> really hurts performance of "other queries". >> >> Given pg_stat_activity output there

Re: [PERFORM] Speed while runnning large transactions.

2009-09-24 Thread jesper
> On Thu, Sep 24, 2009 at 2:27 AM, wrote: >> Hi. >> >> I have a transaction running at the database for around 20 hours .. >> still >> isn't done. But during the last hours it has come to the point where it >> really hurts performance of "other queries". > > What is your transaction doing during

Re: [PERFORM] Speed while runnning large transactions.

2009-09-24 Thread Scott Marlowe
On Thu, Sep 24, 2009 at 2:27 AM, wrote: > Hi. > > I have a transaction running at the database for around 20 hours .. still > isn't done. But during the last hours it has come to the point where it > really hurts performance of "other queries". What is your transaction doing during this time? >

Re: [PERFORM] Speed while runnning large transactions.

2009-09-24 Thread Grzegorz Jaƛkiewicz
On Thu, Sep 24, 2009 at 9:27 AM, wrote: > Hi. > > I have a transaction running at the database for around 20 hours .. still > isn't done. But during the last hours it has come to the point where it > really hurts performance of "other queries". > > Given pg_stat_activity output there seems to be

Re: [PERFORM] Speed while runnning large transactions.

2009-09-24 Thread Claus Guttesen
> I have a transaction running at the database for around 20 hours .. still > isn't done. But during the last hours it has come to the point where it > really hurts performance of "other queries". > > Given pg_stat_activity output there seems to be no locks interfering but > the overall cpu-usage o