MIME-Version: 1.0
In-Reply-To: <87mv71eoep.fsf@jsievers.enova.com>
References: 
 <CAMa1XUi6pbugdB7zUA6weoPjmUHTzNLZcSEAh06-7FZRzkuHQw@mail.gmail.com>
 <CAH2-WznKCt_UBaPEY=WwBof+TkTaDYHbZmDsFE=Vigy3Rqi35A@mail.gmail.com>
 <87mv71eoep.fsf@jsievers.enova.com>
From: Scott Marlowe <scott.marlowe@gmail.com>
Date: Tue, 15 Aug 2017 11:07:26 -0600
Message-ID: 
 <CAOR=d=3+N1467oddeN3E7r2PKELQt+85s+c+JjP-tgRHoYukpA@mail.gmail.com>
Subject: Re: Odd sudden performance degradation related to temp
 object churn
To: Jerry Sievers <gsievers19@comcast.net>
Cc: Peter Geoghegan <pg@bowt.ie>, Jeremy Finzel <finzelj@gmail.com>,
	postgres performance list <pgsql-performance@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On Mon, Aug 14, 2017 at 5:10 PM, Jerry Sievers <gsievers19@comcast.net> wrote:
> Peter Geoghegan <pg@bowt.ie> writes:
>
>> On Mon, Aug 14, 2017 at 12:53 PM, Jeremy Finzel <finzelj@gmail.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?


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance