| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Dimitri <dimitrik(dot)fr(at)gmail(dot)com> |
| Cc: | Aidan Van Dyk <aidan(at)highrise(dot)ca>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Any better plan for this query?.. |
| Date: | 2009-05-12 05:11:40 |
| Message-ID: | 4A09050C.4080009@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Dimitri wrote:
> Now, as you see from your explanation, the Part #2 is the most
> dominant - so why instead to blame this query not to implement a QUERY
> PLANNER CACHE??? - in way if any *similar* query is recognized by
> parser we simply *reuse* the same plan?..
At least in JDBC, there's several open source prepared statement cache
implementations out there that people use. I don't know about other
client libraries, but it certainly is possible to do in the client.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri | 2009-05-12 07:29:08 | Re: Any better plan for this query?.. |
| Previous Message | Scott Marlowe | 2009-05-12 02:38:38 | Re: What is the most optimal config parameters to keep stable write TPS ?.. |