Re: Performance bug in prepared statement binding in 9.2? - Mailing list pgsql-performance

From Jeff Janes
Subject Re: Performance bug in prepared statement binding in 9.2?
Date
Msg-id CAMkU=1wn3npjTjEkC8rYMgmoKXYoAgfxosT_Q3v_=wTfriPKdA@mail.gmail.com
Whole thread Raw
In response to Re: Performance bug in prepared statement binding in 9.2?  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Performance bug in prepared statement binding in 9.2?  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-performance
On Thu, Aug 1, 2013 at 10:58 AM, Josh Berkus <josh@agliodbs.com> wrote:
> Amit, All:
>
> So we just retested this on 9.3b2.  The performance is the same as 9.1
> and 9.2; that is, progressively worse as the test cycles go on, and
> unacceptably slow compared to 8.4.
>
> Some issue introduced in 9.1 is causing BINDs to get progressively
> slower as the PARSEs BINDs get run repeatedly.  Per earlier on this
> thread, that can bloat to 200X time required for a BIND, and it's
> definitely PostgreSQL-side.
>
> I'm trying to produce a test case which doesn't involve the user's
> application.  However, hints on other things to analyze would be keen.

Does it seem to be all CPU time (it is hard to imagine what else it
would be, but...)

Could you use oprofile or perf or gprof to get a profile of the
backend during a run?  That should quickly narrow it down to which C
function has the problem.

Did you test 9.0 as well?

If the connection is dropped and re-established between "cycles" does
the problem still show up?

Cheers,

Jeff


pgsql-performance by date:

Previous
From: Sergey Burladyan
Date:
Subject: Re: Looks like merge join planning time is too big, 55 seconds
Next
From: Scott Marlowe
Date:
Subject: subselect requires offset 0 for good performance.