Re: Performance bug in prepared statement binding in 9.2?

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Performance bug in prepared statement binding in 9.2?
Дата
Msg-id 00b301ce5d3d$697449a0$3c5cdce0$@kapila@huawei.com
обсуждение исходный текст
Ответ на Performance bug in prepared statement binding in 9.2?  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-performance
On Thursday, May 30, 2013 5:45 AM Josh Berkus wrote:
> Folks,
>
> I'm seeing what may be a major performance bug in BIND in 9.2.4.
>
> We have a client who has an application which uses
> Tomcat+Hibernate+JDBC.  They are in the process of upgrading this
> application from 8.4.17 to 9.2.4.  As part of this, they have been
> doing
> performance testing, and 9.2 is coming out MUCH worse than 8.4.  The
> problem appears to be bind/plan time.
>
> Their application does not use prepared queries usefully, doing
> parse,bind,execute on every query cycle.
>
> Here's timings overall for 29 test cycles (cycle 1 has been omitted).
> As you can see, parse+execute times are pretty much constant, as are
> application think times, but bind times vary quite a lot.  In 8.4, the
> 29 cycles are constantly 4.5min to 5.75min long.  In 9.2, which is the
> chart below, they are all over the place.

I think it might be because of choosing custom plan option due to which it might be generating new plan during
exec_bind_message().
exec_bind_message()->GetCachedPlan()->choose_custom_plan(). If it chooses custom plan, then it will regenerate the plan
whichcan cause extra cost 
observed in test.
Though there is calculation that it should not choose custom plan always, but still I guess the variation observed in
thetest can be due to this reason. 

To test if this is the cause, we might hack the code such that it always chooses generic plan, so that it doesn't need
togenerate plan again. 

With Regards,
Amit Kapila.



В списке pgsql-performance по дате отправления:

Предыдущее
От: itishree sukla
Дата:
Сообщение: Re: Check Pointer
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: Slow SELECT by primary key? Postgres 9.1.2