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 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. 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
