From: | Dimitri <dimitrik(dot)fr(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(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 07:36:31 |
Message-ID: | 5482c80a0905120036q56724b30l231d4e317c313665@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Nice to know. But again, if this cache is kept only on the client side
it'll be always lost on disconnect. And if clients are "short-lived"
it'll not help.
BTW, is there an option to say "do execution plan as simple as
possible"? If you're sure about your data and your indexes - don't
need to spend so much time.
Rgds,
-Dimitri
On 5/12/09, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> 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 | Andres Freund | 2009-05-12 07:43:13 | Re: Any better plan for this query?.. |
Previous Message | Dimitri | 2009-05-12 07:29:08 | Re: Any better plan for this query?.. |