MIME-Version: 1.0
In-Reply-To: 
 <CADrzpjG3SDW1OxAFrYVNq63M6WA_y=DL27DenZ=tHmr=6L6Y0w@mail.gmail.com>
References: 
 <CADrzpjHChC6q0NGMG0wZUFvj-A0QO3WL9JONLcmRRCZuPnQQNQ@mail.gmail.com>
 <1507042486.2998.1.camel@cybertec.at>
 <CADrzpjG3SDW1OxAFrYVNq63M6WA_y=DL27DenZ=tHmr=6L6Y0w@mail.gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Wed, 11 Oct 2017 16:20:36 +0200
Message-ID: 
 <CAFj8pRCnzVUz69PNKwUZWeGP7P0xv0QznB_bwHHhgogLcqeo1w@mail.gmail.com>
Subject: Re: Stored Procedure Performance
To: Purav Chovatia <puravc@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Content-Type: multipart/alternative; boundary="001a1142427e0ab083055b462392"
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

--001a1142427e0ab083055b462392
Content-Type: text/plain; charset="UTF-8"

2017-10-11 15:59 GMT+02:00 Purav Chovatia <puravc@gmail.com>:

> Thanks Laurenz, am having a look at perf.
>
> Can you pls help understand what exactly do you mean when you say "PL/pgSQL
> is not optimized for performance like PL/SQL". Do you mean to indicate that
> app firing queries/DMLs directly would be a better option as compared to
> putting those in Stored Procs?
>

PL/pgSQL is perfect glue for SQL. SQL queries has same speed without
dependency on environment that executed it.

This sentence mean, so PLpgSQL is not designed for intensive mathematics
calculation.  PL/SQL is self govering environment ... it has own data
types, it has own implementation of logical and mathematics operators.
PLpgSQL is layer over SQL engine - and has not own types, has not own
operators. Any expression is translated to SQL and then is interpreted by
SQL expression interpret. Maybe in next few years there will be a JIT
compiler. But it is not now. This is current bottleneck of PLpgSQL. If your
PL code is glue for SQL queries (implementation of some business
processes), then PLpgSQL is fast enough. If you try to calculate numeric
integration or derivation of some functions, then PLpgSQL is slow. It is
not too slow - the speed is comparable with PHP, but it is significantly
slower than C language.

PostgreSQL has perfect C API - so intensive numeric calculations are
usually implemented as C extension.

Regards

Pavel


>
> Regards
>
> On 3 October 2017 at 20:24, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
>> Purav Chovatia wrote:
>> > I come from Oracle world and we are porting all our applications to
>> postgresql.
>> >
>> > The application calls 2 stored procs,
>> > - first one does a few selects and then an insert
>> > - second one does an update
>> >
>> > The main table on which the insert and the update happens is truncated
>> before every performance test.
>> >
>> > We are doing about 100 executions of both of these stored proc per
>> second.
>> >
>> > In Oracle each exec takes about 1millisec whereas in postgres its
>> taking 10millisec and that eventually leads to a queue build up in our
>> application.
>> >
>> > All indices are in place. The select, insert & update are all single
>> row operations and use the PK.
>> >
>> > It does not look like any query taking longer but something else. How
>> can I check where is the time being spent? There are no IO waits, so its
>> all on the CPU.
>>
>> You could profile the PostgreSQL server while it is executing the
>> workload,
>> see for example https://wiki.postgresql.org/wiki/Profiling_with_perf
>>
>> That way you could see where the time is spent.
>>
>> PL/pgSQL is not optimized for performance like PL/SQL.
>>
>> Yours,
>> Laurenz Albe
>>
>
>

--001a1142427e0ab083055b462392
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2017-10-11 15:59 GMT+02:00 Purav Chovatia <span dir=3D"ltr">&lt;<a href=
=3D"mailto:puravc@gmail.com" target=3D"_blank">puravc@gmail.com</a>&gt;</sp=
an>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Thanks Laurenz, am =
having a look at perf.<div><br></div><div>Can you pls help understand what =
exactly do you mean when you say &quot;<span style=3D"font-size:12.8px">PL/=
pgSQL is not optimized for performance like PL/SQL&quot;. Do you mean to in=
dicate that app firing queries/DMLs directly would be a better option as co=
mpared to putting those in Stored Procs?</span></div></div></blockquote><di=
v><br></div><div>PL/pgSQL is perfect glue for SQL. SQL queries has same spe=
ed without dependency on environment that executed it.</div><div><br></div>=
<div>This sentence mean, so PLpgSQL is not designed for intensive mathemati=
cs calculation.=C2=A0 PL/SQL is self govering environment ... it has own da=
ta types, it has own implementation of logical and mathematics operators. P=
LpgSQL is layer over SQL engine - and has not own types, has not own operat=
ors. Any expression is translated to SQL and then is interpreted by SQL exp=
ression interpret. Maybe in next few years there will be a JIT compiler. Bu=
t it is not now. This is current bottleneck of PLpgSQL. If your PL code is =
glue for SQL queries (implementation of some business processes), then PLpg=
SQL is fast enough. If you try to calculate numeric integration or derivati=
on of some functions, then PLpgSQL is slow. It is not too slow - the speed =
is comparable with PHP, but it is significantly slower than C language.</di=
v><div><br></div><div>PostgreSQL has perfect C API - so intensive numeric c=
alculations are usually implemented as C extension.</div><div><br></div><di=
v>Regards</div><div><br></div><div>Pavel<br></div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:12.8p=
x"><br></span></div><div><span style=3D"font-size:12.8px">Regards</span></d=
iv></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On 3 October 2017 at 20:24, Laurenz Albe <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:laurenz.albe@cybertec.at" target=3D"_=
blank">laurenz.albe@cybertec.at</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Purav Chovatia wrote:<br>
&gt; I come from Oracle world and we are porting all our applications to po=
stgresql.<br>
&gt;<br>
&gt; The application calls 2 stored procs,=C2=A0<br>
&gt; - first one does a few selects and then an insert<br>
&gt; - second one does an update<br>
&gt;<br>
&gt; The main table on which the insert and the update happens is truncated=
 before every performance test.<br>
&gt;<br>
&gt; We are doing about 100 executions of both of these stored proc per sec=
ond.<br>
&gt;<br>
&gt; In Oracle each exec takes about 1millisec whereas in postgres its taki=
ng 10millisec and that eventually leads to a queue build up in our applicat=
ion.<br>
&gt;<br>
&gt; All indices are in place. The select, insert &amp; update are all sing=
le row operations and use the PK.<br>
&gt;<br>
&gt; It does not look like any query taking longer but something else. How =
can I check where is the time being spent? There are no IO waits, so its al=
l on the CPU.<br>
<br>
You could profile the PostgreSQL server while it is executing the<br>
workload,<br>
see for example <a href=3D"https://wiki.postgresql.org/wiki/Profiling_with_=
perf" rel=3D"noreferrer" target=3D"_blank">https://wiki.postgresql.org/wi<w=
br>ki/Profiling_with_perf</a><br>
<br>
That way you could see where the time is spent.<br>
<br>
PL/pgSQL is not optimized for performance like PL/SQL.<br>
<br>
Yours,<br>
Laurenz Albe<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>

--001a1142427e0ab083055b462392--