Re: [PERFORMANCE] Stored Procedures

От: Rikard Pavelic
Тема: Re: [PERFORMANCE] Stored Procedures
Дата: ,
Msg-id: 43D2A245.6040804@zg.htnet.hr
(см: обсуждение, исходный текст)
Ответ на: 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:
> If you're dealing with something that's performance critical you're not
> going to be constantly re-connecting anyway, so I don't see what the
> issue is.
>

I didn't include mailing list in my second reply :( so here it is again.
Someone may find this interesting...

http://archives.postgresql.org/pgsql-general/2004-04/msg00084.php

 From Tom Lane:
"EXECUTE means something different in plpgsql than it does in plain SQL,

and you do not need PREPARE at all in plpgsql.  plpgsql's automatic
caching of plans gives you the effect of PREPARE on every statement
without your having to ask for it."



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

От: Tom Lane
Дата:
Сообщение: Re: libpq vs. unixODBC performance
От: pgsql-performance@nullmx.com
Дата:
Сообщение: tsearch2 headline and postgresql.conf