| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Performance bug in prepared statement binding in 9.2? |
| Date: | 2013-05-31 18:54:15 |
| Message-ID: | 51A8F1D7.2000109@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> When you say interactively, does it mean that you are using psql to test the same?
Yes. Of course, on the psql command line, there's no separate BIND
step, just PREPARE and EXECUTE.
> From the changes, it doesn't seem that any of such changes can cause the problem you have seen.
No, but clearly in this case something is broken.
> Do you think it can be due to
> a. JDBC - communication, encoding or some other changes
> b. can we assume that plans generated for all statements are same, if not it might have some cost for query plan initialization (InitPlan) but again it should not be that big cost.
I don't think we can assume that, no.
> How do measure individual bind time cost (is the cost of only server side or it includes client bind or ..)?
From the PostgreSQL activity log. BIND gets logged separately.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2013-06-01 02:38:19 | Re: Best practice when reindexing in production |
| Previous Message | Marti Raudsepp | 2013-05-31 16:57:19 | Re: [PERFORM] Evaluating query performance with caching in PostgreSQL 9.1.6 |