Re: Performance bug in prepared statement binding in 9.2?

We're currently using an embedded PG 8.4.17 for our application. Our PG 9.x tests consists of one of the following :

- Take a 8.4.17 DB which contains only our application schema and required seed data and use pg_upgrade to create a 9.x database directory, run the analyze_new_cluster.sh script and fire up the application. Under this set of conditions, the bind connection issue is present during our test.

- Start with a fresh PG 9.x DB (using use create_db) and use psql to recreate our application schema and required seed data. When the application is started and our test executed, the bind connection issue is still present.

In both of the above cases, a base application schema is used.

If I upgrade an 8.4.17 DB that contains additional application data (generated by interaction with our application) to 9.x, the bind connection issue is no longer present. Restoring this upgraded 9.x DB into any PG instance in the previously described scenarios also seems to fix the bind connection issue.

Please let me know if this clarifies my earlier post.

Thanks, M.

Mel Llaguno | Principal Engineer (Performance/Deployment)
Coverity | 800 6th Avenue S.W. | Suite 410 | Calgary, AB | Canada | T2P 3G3
mllaguno(at)coverity(dot)com
________________________________________
From: Bruce Momjian [bruce(at)momjian(dot)us]
Sent: Monday, September 09, 2013 7:45 PM
To: Mel Llaguno
Cc: Andrew Dunstan; Jeff Janes; Josh Berkus; Amit Kapila;
pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Performance bug in prepared statement binding in
9.2?

On Tue, Sep 10, 2013 at 01:36:27AM +0000, Mel Llaguno wrote:
> Let me clarify further - when we reconstruct our schema (without the
> upgrade step) via a sql script, the problem still persists. Restoring
> an upgraded DB which contains existing data into exactly the same
> instance will correct the behavior.

I do not understand what you are saying above.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +