2013/2/5 Bruce Momjian <bruce@momjian.us>:
> On Mon, Feb 4, 2013 at 08:33:02AM -0600, Merlin Moncure wrote:
>> On Sat, Feb 2, 2013 at 11:36 AM, Carlo Stonebanks
>> <stonec.register@sympatico.ca> wrote:
>> > Here is an advantage Plpgsql has:
>> > http://www.postgresql.org/docs/9.1/static/plpgsql-expressions.html
>> >
>> > I guess you can offset this by creating your own prepared statements i=
n C.
>> > Otherwise, I can=E2=80=99t think of how C could be slower. I would cho=
ose C for
>> > functions that don=E2=80=99t have SQL statements in them =E2=80=93 e.g=
. math and string
>> > processing.
>>
>> For cases involving data processing (SPI calls), C can be slower
>> because pl/pgsql has a lot of optimizations in it that can be very
>> easy to miss. I don't suggest writing backend C functions at all
>> unless you are trying to interface with a C library to access
>> functionality currently not exposed in SQL.
>
> How is PL/pgSQL faster than C? I thought we had optimized PL/pgSQL to
> save parsed functions, but I don't see how that would help with queries,
> which use SPI. Am I missing something?
PL/pgSQL can be faster than badly written C functions if there are
bottle neck is in server side routines. Any well written C code will
be faster then well written PL/pgSQL - how much depends on specific
use case. If bottle neck is in IO op, then not too much - PL/pgSQL has
not any specific optimization, that cannot be used in C.
Regards
Pavel
>
> --
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
