Amit,
> 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
planwhich 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
thetest can be due to this reason.
This is why I'm asking them to run tests on 9.1. If 9.1 doesn't exhibit
this behavior, then customplan is liable to be at fault.
HOWEVER, that doesn't explain why creating a plan for a query during
application operation would take 80ms, but only 1.2ms when I do it
interactively.
FYI, per questions from IRC: the times for each "cycle" in my data are
cumulative minutes. Each cycle runs around 500,000 queries, so that's
the aggregate across all queries.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
