Re: plpgsql functions organisation

[Melvin Davidson <melvin6925@xxxxxxxxx>]

Further to the point of saying functions are ineffiencent, consider the fact that as of the current version of PostgreSQL, plpgsql

functions cannot be pre-optimized. So when they are referenced in a SQL statement, PostgreSQL (optimizer) has load the

function from the catalogs, which involves overhead. If the function calls another function, then the process has to be repeated, which involves additional overhead. Ergo, that is not the most efficient way of doing things.

On Sat, May 2, 2015 at 5:17 PM, Bill Moran <wmoran@xxxxxxxxxxxxxxxxx> wrote:

On Sat, 2 May 2015 14:07:31 -0700
Jeff Janes <jeff.janes@xxxxxxxxx> wrote:

> On Sat, May 2, 2015 at 1:05 PM, Adrian Klaver <adrian.klaver@xxxxxxxxxxx>
> wrote:
>
> > On 05/02/2015 10:12 AM, Melvin Davidson wrote:
> >
> >> AFAIK, you cannot "package" functions in  PostgreSQL, but it is possible
> >> to
> >> call a function from within a function.
> >>
> >> That being said, I would seriously look at how and why you are writing
> >> your functions
> >> as functions that call other functions are not very efficient.
> >>
> >
> > I am not following. That is what packaging is about, separating out 'units
> > of work' so they can be combined as needed. Part of that is using existing
> > functions in new functions/classes. In fact in the Postgres source I see
> > this in many places. Now it is entirely possible I missed a memo, so I am
> > open to a more detailed explanation of the inefficiencies involved.
> >
>
> The Postgres source is written in C, not in plpgsql.  C has a good
> optimizing compiler and plpgsql doesn't.

Maybe that's a roundabout way of saying that if your functions are
complex enough to require calling "sub-functions" they might be
justifying being writting in C?

--
Bill Moran

--

Melvin Davidson
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.