Thread: Embedding code in Postgres source code

Hi,

I have a stored procedure that gets called every now and then in my system. This stored procedure is an implementation of client socket code basically.

If somehow this stored procedure becomes a part of Postgres source code, would it really make any difference as far as performance and resource utilization of my system is concerned ?

Thanks,
Hapreet

Hello

If your stored procedure is writen in C language, then storing it
inside PostgreSQL hasn't any benefit. There is only one difference ..
loading library needs some time, but you can load any library with
statement LOAD.

Regards
Pavel Stehule





2007/10/7, Harpreet Dhaliwal <harpreet.dhaliwal01@gmail.com>:
> Hi,
>
> I have a stored procedure that gets called every now and then in my system.
> This stored procedure is an implementation of client socket code basically.
>
> If somehow this stored procedure becomes a part of Postgres source code,
> would it really make any difference as far as performance and resource
> utilization of my system is concerned ?
>
> Thanks,
> Hapreet
>

My stored procedure is in Perl. Does that really make any difference ?

2007/10/7, Harpreet Dhaliwal <harpreet.dhaliwal01@gmail.com>:
> My stored procedure is in Perl. Does that really make any difference ?
>
It depends. If you call external libraries you can be little bit
faster. You have to test it.

Pavel



> On 10/7/07, Pavel Stehule <pavel.stehule@gmail.com > wrote:
> > Hello
> >
> > If your stored procedure is writen in C language, then storing it
> > inside PostgreSQL hasn't any benefit. There is only one difference ..
> > loading library needs some time, but you can load any library with
> > statement LOAD.
> >
> > Regards
> > Pavel Stehule
> >
> >
> >
> >
> >
> > 2007/10/7, Harpreet Dhaliwal <harpreet.dhaliwal01@gmail.com>:
> > > Hi,
> > >
> > > I have a stored procedure that gets called every now and then in my
> system.
> > > This stored procedure is an implementation of client socket code
> basically.
> > >
> > > If somehow this stored procedure becomes a part of Postgres source code,
> > > would it really make any difference as far as performance and resource
> > > utilization of my system is concerned ?
> > >
> > > Thanks,
> > > Hapreet
> > >
> >
>
>

Faster by calling external or internal libraries. my concept was calling libraries internal to the system would make it faster right ?

2007/10/7, Harpreet Dhaliwal <harpreet.dhaliwal01@gmail.com>:
> Faster by calling external or internal libraries. my concept was calling
> libraries internal to the system would make it faster right ?
>

I thing, so it's not true, because all libraries functions are
directly called. It is different than Microsoft Windows.

Pavel



>
> On 10/7/07, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> > 2007/10/7, Harpreet Dhaliwal <harpreet.dhaliwal01@gmail.com>:
> > > My stored procedure is in Perl. Does that really make any difference ?
> > >
> > It depends. If you call external libraries you can be little bit
> > faster. You have to test it.
> >
> > Pavel
> >
> >
> >
> > > On 10/7/07, Pavel Stehule <pavel.stehule@gmail.com > wrote:
> > > > Hello
> > > >
> > > > If your stored procedure is writen in C language, then storing it
> > > > inside PostgreSQL hasn't any benefit. There is only one difference ..
> > > > loading library needs some time, but you can load any library with
> > > > statement LOAD.
> > > >
> > > > Regards
> > > > Pavel Stehule
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 2007/10/7, Harpreet Dhaliwal <harpreet.dhaliwal01@gmail.com>:
> > > > > Hi,
> > > > >
> > > > > I have a stored procedure that gets called every now and then in my
> > > system.
> > > > > This stored procedure is an implementation of client socket code
> > > basically.
> > > > >
> > > > > If somehow this stored procedure becomes a part of Postgres source
> code,
> > > > > would it really make any difference as far as performance and
> resource
> > > > > utilization of my system is concerned ?
> > > > >
> > > > > Thanks,
> > > > > Hapreet
> > > > >
> > > >
> > >
> > >
> >
>
>