Re: Performance bug in prepared statement binding in 9.2?

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Performance bug in prepared statement binding in 9.2?
Date: 2013-08-01 19:20:39
Message-ID: CAMkU=1wn3npjTjEkC8rYMgmoKXYoAgfxosT_Q3v_=wTfriPKdA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Aug 1, 2013 at 10:58 AM, Josh Berkus <josh(at)agliodbs(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2013-08-01 19:40:41 subselect requires offset 0 for good performance.
Previous Message Sergey Burladyan 2013-08-01 19:13:26 Re: Looks like merge join planning time is too big, 55 seconds