Dne 4.4.2011 16:32, Kevin Grittner napsal(a):
> Nothing there makes a write glut on checkpoint less likely to be the
> cause. Without a BBU write-back cache it is actually *more* likely,
> and having enough RAM to hold the whole database makes it *more*
> likely. If you haven't placed your pg_xlo
Lars Feistner wrote:
> On 03/30/2011 06:54 PM, Kevin Grittner wrote:
>> If you haven't already done so, you should probably turn on
>> checkpoint logging to see if this corresponds to checkpoint
>> activity. If it does, you can try cranking up how aggressive
>> your background writer is, and pe
On 03/30/2011 06:54 PM, Kevin Grittner wrote:
Lars Feistner wrote:
On 03/29/2011 09:28 PM, Kevin Grittner wrote:
Lars Feistner wrote:
The log tells me that certain update statements take sometimes
about 3-10 minutes. But we are talking about updates on tables
with 1000 to 1 rows and
Lars Feistner wrote:
> On 03/29/2011 09:28 PM, Kevin Grittner wrote:
>> Lars Feistner wrote:
>>
>>> The log tells me that certain update statements take sometimes
>>> about 3-10 minutes. But we are talking about updates on tables
>>> with 1000 to 1 rows and updates that are supposed to update
2011/3/30, Lars Feistner :
> Hello Kevin,
>
>
> On 03/29/2011 09:28 PM, Kevin Grittner wrote:
>> Lars Feistner wrote:
>>
>>> The log tells me that certain update statements take sometimes
>>> about 3-10 minutes. But we are talking about updates on tables
>>> with 1000 to 1 rows and updates tha
Hello Kevin,
On 03/29/2011 09:28 PM, Kevin Grittner wrote:
Lars Feistner wrote:
The log tells me that certain update statements take sometimes
about 3-10 minutes. But we are talking about updates on tables
with 1000 to 1 rows and updates that are supposed to update 1
row.
The top possi
Lars Feistner wrote:
> The log tells me that certain update statements take sometimes
> about 3-10 minutes. But we are talking about updates on tables
> with 1000 to 1 rows and updates that are supposed to update 1
> row.
The top possibilities that come to my mind are:
(1) The tables ar
