Re: Performance: sql functions v. plpgsql v. plperl

Поиск
Список
Период
Сортировка
От Joel Burton
Тема Re: Performance: sql functions v. plpgsql v. plperl
Дата
Msg-id Pine.LNX.4.21.0104251656370.15130-100000@olympus.scw.org
обсуждение исходный текст
Ответ на Re: Performance: sql functions v. plpgsql v. plperl  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Performance: sql functions v. plpgsql v. plperl  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On Wed, 25 Apr 2001, Tom Lane wrote:

> Joel Burton <jburton@scw.org> writes:
> > Last night, I was doing some amateurish benchmarking and found that,
> > contrary to my (admittedly uninformed) expectation, sql functions seem
> > *slower* than plsql functions.
>
> IIRC, sql functions are re-parsed/planned on each execution, whereas
> plpgsql functions cache their parse trees and execution plans.
> Depending on exactly what you were doing, that might explain the
> difference.

Why is this?

I'm just delving into the source code in earnest for the first time, so,
forgive any awful errors, but it seems like we have the plumbing for this
in views/rules... couldn't the parse tree be cached from this for each
backend?

Or are SQL functions mildly deprecated since they could always be replaced
by the plpgsql function

begin
  return ...
end;

?


--
Joel Burton   <jburton@scw.org>
Director of Information Systems, Support Center of Washington


В списке pgsql-general по дате отправления:

Предыдущее
От: Jan Ploski
Дата:
Сообщение: Re: SUM()ming a view's column
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Performance: sql functions v. plpgsql v. plperl