Re: Performance degradation in 324577f39bc8738ed0ec24c36c5cb2c2f81ec660

From: Vladimir Kamarzin <vvk(at)vvk(dot)pp(dot)ru>
To: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Performance degradation in 324577f39bc8738ed0ec24c36c5cb2c2f81ec660
Date: 2014-10-08 08:40:23
Message-ID: 2012271412757623@web3g.yandex.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


07.10.2014, 19:59, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Vladimir Kamarzin <vvk(at)vvk(dot)pp(dot)ru> writes:
>>  After upgrade from 9.3.1 to 9.3.5 we expirienced a slight performance degradation of all queries. Query time increased to some amount of ms, mostly in range of 100ms. Some actions in our application results in a lot of small queries and in such cases performance degradation is very significant - total action performs for a 2-3 times longer then before (15s -> 40s, etc).
>>  Using git-bisect we've found a bad revision causes performance drop: it is 324577f39bc8738ed0ec24c36c5cb2c2f81ec660
>
> Hm.  If you're going to do queries that involve update/delete across large
> inheritance trees, that bug fix is unavoidably going to cost you some
> cycles.

Yeah, we're actually noticed significantly increased CPU load while running on 9.3.5.

> I am wondering if you've
> misidentified the commit that made the difference --- especially since you
> claim there's a penalty for "all" queries, which there manifestly couldn't
> be with this particular patch.

No, problem appears exactly on this commit. Actually I don't really sure about "all": we don't see degradation when performing plain SELECTs manually,
but comparing logged query time of some SELECTs we see the differences.

Here is example 42ms -> 250ms:
http://pastebin.ca/2855292
http://pastebin.ca/2855290

>  If not, there must be something rather
> unusual about your queries or schema.  Care to provide a self-contained
> test case?

I'm afraid we cannot do this now. If you wish, we can give you ssh access to the test server to investigate the problem.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Andrey Lizenko 2014-10-08 09:48:35 Re: query plan question, nested loop vs hash join
Previous Message and 2014-10-08 06:35:02 Bad optimization/planning on Postgres window-based queries (partition by(, group by?)) - 1000x speedup