Re: Performance bug in prepared statement binding in 9.2?

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Performance bug in prepared statement binding in 9.2?
Дата
Msg-id CAMkU=1wn3npjTjEkC8rYMgmoKXYoAgfxosT_Q3v_=wTfriPKdA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Performance bug in prepared statement binding in 9.2?  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Performance bug in prepared statement binding in 9.2?
Список 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 по дате отправления:

Предыдущее
От: Sergey Burladyan
Дата:
Сообщение: Re: Looks like merge join planning time is too big, 55 seconds
Следующее
От: Scott Marlowe
Дата:
Сообщение: subselect requires offset 0 for good performance.