Bruce, First of all, I'd like to thank you for taking some interest in this issue. We'd love to migrate to the latest PG version, but this issue is currently preventing us from doing so. Regardless of the DB used (base application schema _or_ restored DB with additional app data + base application schema), seed information is present in all tests. I guess my question is this - why would having existing data change the bind behavior at all? Is it possible that the way indexes are created has changed between 8.4 -> 9.x? Thanks, M. Mel Llaguno | Principal Engineer (Performance/Deployment) Coverity | 800 6th Avenue S.W. | Suite 410 | Calgary, AB | Canada | T2P 3G3 mllaguno@xxxxxxxxxxxx ________________________________________ From: Bruce Momjian [bruce@xxxxxxxxxx] Sent: Monday, September 09, 2013 8:16 PM To: Mel Llaguno Cc: pgsql-performance@xxxxxxxxxxxxxx Subject: Re: Performance bug in prepared statement binding in 9.2? On Tue, Sep 10, 2013 at 02:06:08AM +0000, Mel Llaguno wrote: > 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. Yes, that is clear. So it is the seed data that is causing the problem? That is the only different I see from #2 and #3. -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
