From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Jerry Sievers <gsievers19(at)comcast(dot)net> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Jeremy Finzel <finzelj(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Odd sudden performance degradation related to temp object churn |
Date: | 2017-08-15 17:07:26 |
Message-ID: | CAOR=d=3+N1467oddeN3E7r2PKELQt+85s+c+JjP-tgRHoYukpA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Aug 14, 2017 at 5:10 PM, Jerry Sievers <gsievers19(at)comcast(dot)net> wrote:
> Peter Geoghegan <pg(at)bowt(dot)ie> writes:
>
>> On Mon, Aug 14, 2017 at 12:53 PM, Jeremy Finzel <finzelj(at)gmail(dot)com> wrote:
>>
>>> This particular db is on 9.3.15. Recently we had a serious performance
>>> degradation related to a batch job that creates 4-5 temp tables and 5
>>> indexes. It is a really badly written job but what really confuses us is
>>> that this job has been running for years with no issue remotely approaching
>>> this one. We are also using pgpool.
>>
>> Did you happen to notice that this occurred when you upgrading point
>> release? If so, what version did you move from/to?
>
> The system was last started back in November. Running 9.3.15.
>
> Not aware of any host system libs or whatever change recently but will investigate.
So do iostat or iotop show you if / where your disks are working
hardest? Or is this CPU overhead that's killing performance?
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2017-08-15 17:14:14 | Re: performance problem on big tables |
Previous Message | Scott Marlowe | 2017-08-15 17:04:58 | Re: Odd sudden performance degradation related to temp object churn |