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
thebind 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@coverity.com
________________________________________
From: Bruce Momjian
[bruce@momjian.us]
Sent: Monday, September 09, 2013 8:16 PM
To: Mel
Llaguno
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM]
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@momjian.us>
http://momjian.us
EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +