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 по дате отправления:

Предыдущее
От: Dimitri
Дата:
Сообщение: Re: Any better plan for this query?..
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Any better plan for this query?..