Re: Performance bug in prepared statement binding in 9.2?

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 which can 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 the test 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 to generate plan again.

With Regards,
Amit Kapila.