| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Any better plan for this query?.. |
| Дата | |
| Msg-id | 4A09050C.4080009@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: Any better plan for this query?.. (Dimitri <dimitrik.fr@gmail.com>) |
| Ответы |
Re: Any better plan for this query?..
|
| Список | 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
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера