Re: [PERFORMANCE] Stored Procedures

От: Rikard Pavelic
Тема: Re: [PERFORMANCE] Stored Procedures
Дата: ,
Msg-id: 43D13C2F.1030203@zg.htnet.hr
(см: обсуждение, исходный текст)
Ответ на: Re: [PERFORMANCE] Stored Procedures  ("Jim C. Nasby")
Ответы: Re: [PERFORMANCE] Stored Procedures  ("Jim C. Nasby")
Список: pgsql-performance

Скрыть дерево обсуждения

Re: [PERFORMANCE] Stored Procedures  (Rikard Pavelic, )
 Re: [PERFORMANCE] Stored Procedures  ("Jim C. Nasby", )
  Re: [PERFORMANCE] Stored Procedures  (Rikard Pavelic, )
   Re: [PERFORMANCE] Stored Procedures  ("Jim C. Nasby", )
    Re: [PERFORMANCE] Stored Procedures  (Rikard Pavelic, )
    Re: [PERFORMANCE] Stored Procedures  (Rikard Pavelic, )
    Re: [PERFORMANCE] Stored Procedures  (Marcos, )
     Re: [PERFORMANCE] Stored Procedures  (Markus Schaber, )
      Re: [PERFORMANCE] Stored Procedures  (Marcos, )
       Re: [PERFORMANCE] Stored Procedures  ("Dave Dutcher", )
        Re: [PERFORMANCE] Stored Procedures  (Frank Wiles, )

Jim C. Nasby wrote:
> My college professor said it, it must be true! ;P
>
>
The famous joke ;)
> My understanding is that in plpgsql, 'bare' queries get prepared and act
> like prepared statements. IE:
>
> SELECT INTO variable
>     field
>     FROM table
>     WHERE condition = true
> ;
>
>
Unfortunately I don't know enough about PostgreSQL, but from responses
I've been reading I've
come to that conclusion.
> Ok, so post some numbers then. It might be interesting to look at the
> cost of preparing a statement, although AFAIK that does not store the
> query plan anywhere.
>
> In most databases, query planning seems to be a pretty expensive
> operation. My experience is that that isn't the case with PostgreSQL.
>

I didn't think about storing query plan anywhere on the disk, rather
keep them in memory pool.
It would be great if we had an option to use prepare statement for
stored procedure so it
would prepare it self the first time it's called and remained prepared
until server shutdown or
memory pool overflow.

This would solve problems with prepare which is per session, so for
prepared function to be
optimal one must use same connection.


В списке pgsql-performance по дате сообщения:

От: "Craig A. James"
Дата:
Сообщение: Re: [GENERAL] Creation of tsearch2 index is very slow
От: Rikard Pavelic
Дата:
Сообщение: Re: [PERFORMANCE] Stored Procedures