From: | Harry Mantheakis <harry(dot)mantheakis(at)riskcontrollimited(dot)com> |
---|---|
To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Long Running Update |
Date: | 2011-06-24 12:39:16 |
Message-ID: | 4E048574.6010706@riskcontrollimited.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Thanks again Claudio.
It does not look like its locked/blocked - but your hint about doing
this task in smaller batches is a good one, and it would be easy enough
to organise.
I am going to let this task run over the week-end, and then decide.
Either way, I shall update this thread.
Much obliged!
Harry Mantheakis
London, UK
On 24/06/2011 12:39, Claudio Freire wrote:
> On Fri, Jun 24, 2011 at 1:19 PM, Harry Mantheakis
> <harry(dot)mantheakis(at)riskcontrollimited(dot)com> wrote:
>>> there are lots of ways in which it could be struggling...
>> I have been monitoring the server with IOSTAT -d and IOSTAT -c and I cannot
>> see anything alarming.
> If iostat doesn't show disk load, either iostat doesn't work well
> (which could be the case, I've found a few broken installations here
> and there), or, perhaps, your update is waiting on some other update.
>
> I've seen cases when there are application-level deadlocks (ie,
> deadlocks, but that the database alone cannot detect, and then your
> queries stall like that. It happens quite frequently if you try such a
> massive update on a loaded production server. In those cases, the
> technique someone mentioned (updating in smaller batches) usually
> works nicely.
>
> You should be able to see if it's locked waiting for something with
> "select * from pg_stat_activity".
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Thornton | 2011-06-24 12:52:43 | Re: Long Running Update |
Previous Message | Vitalii Tymchyshyn | 2011-06-24 11:45:15 | Re: Long Running Update |