Re: Any better plan for this query?..
От | Dimitri |
---|---|
Тема | Re: Any better plan for this query?.. |
Дата | |
Msg-id | 5482c80a0905120036q56724b30l231d4e317c313665@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Any better plan for this query?.. (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | 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.linnakangas@enterprisedb.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 >
В списке pgsql-performance по дате отправления: