Re: [PERFORMANCE] Stored Procedures
От
Rikard Pavelic
Тема
Re: [PERFORMANCE] Stored Procedures
Дата
Msg-id
43D2A245.6040804@zg.htnet.hr
Ответ на
Re: [PERFORMANCE] Stored Procedures (Jim C. Nasby)
Список
Дерево обсуждения
Re: [PERFORMANCE] Stored Procedures Rikard Pavelic <rikard.pavelic@zg.htnet.hr>
Re: [PERFORMANCE] Stored Procedures "Jim C. Nasby" <jnasby@pervasive.com>
Re: [PERFORMANCE] Stored Procedures Rikard Pavelic <rikard.pavelic@zg.htnet.hr>
Re: [PERFORMANCE] Stored Procedures "Jim C. Nasby" <jnasby@pervasive.com>
Re: [PERFORMANCE] Stored Procedures Marcos <mjs_ops@gmx.net>
Re: [PERFORMANCE] Stored Procedures Markus Schaber <schabi@logix-tt.com>
Re: [PERFORMANCE] Stored Procedures Marcos <mjs_ops@gmx.net>
Re: [PERFORMANCE] Stored Procedures "Dave Dutcher" <dave@tridecap.com>
Re: [PERFORMANCE] Stored Procedures Frank Wiles <frank@wiles.org>
Re: [PERFORMANCE] Stored Procedures Rikard Pavelic <rikard.pavelic@zg.htnet.hr>
Re: [PERFORMANCE] Stored Procedures Rikard Pavelic <rikard.pavelic@zg.htnet.hr>
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 по дате отправления
