Re: Any better plan for this query?..

Поиск
Список
Период
Сортировка
От 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?..  (Dimitri <dimitrik.fr@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: What is the most optimal config parameters to keep stable write TPS ?..
Следующее
От: Dimitri
Дата:
Сообщение: Re: Any better plan for this query?..