Re: Sun acquires MySQL

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Alex Turner" <armtuk(at)gmail(dot)com>
Cc: "Martin Gainty" <mgainty(at)hotmail(dot)com>, walterbyrd <walterbyrd(at)iname(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Sun acquires MySQL
Date: 2008-01-21 08:10:43
Message-ID: 162867790801210010r4d04c245md5a86f2084da97bc@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 21/01/2008, Alex Turner <armtuk(at)gmail(dot)com> wrote:
> I love Postgresql to death, it's one of the shining stars of the Open Source
> movement IMHO. It's rock solid, crashes less frequently than Oracle in my
> experience, and does almost everything I could ask of it (granted - I don't
> ask much often, just simple things like consistent behaviour, which seems to
> elude many other products). My one biggest bone to pick with Postgresql is
> that stored procedures are not compiled. It makes writing anything but the
> most trivial things in plpgsql stupid because it will slow the crap out of
> your queries. For example: I wrote a simple function to return the distance
> between two lat longs in plpgsql. Not only did it choke on values that were
> part of a valid domain when calling acos() (I have a list of them someplace
> that I keep meaning to post as it seems like a really bad bug), it was slow.
> I re-implemented in C and it was 8-12 times faster, and didn't error out on
> acos for the same values. Expecting DBAs to be able to write functions in C
> IMHO is a bit unrealistic. I am far from a typical DBA, I've met precious
> few Oracle DBAs who could write functions in C. Trying to implement good
> database code that is atomic and makes good use of functions in Postgresql
> is an uphill battle because they slow the database down so much.

Usability of plpgsql depend on case. There are some case where plpgsql
is useless: http://www.pgsql.cz/index.php/PL/pgSQL_%28en%29#When_is_PL.2FpgSQL_not_applicable

when you use plpgsql as glue of SQL statements, then speed of plpgsql
>> speed of SQL statements and there isn't problem. Your example is
real and I understand well, but bottleneck isn't in interpretation, is
it in evaluation of basic types, where C do this work simply and fast
and plpgsql call SQL expression evaluator. I am not sure if its
possible to write compiler for all supported platforms. I thinking
about plpgsql->c translator with some intelligence for detecting some
simply operations. Any sponsors?

Regards
Pavel Stehule

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Albe Laurenz 2008-01-21 08:15:44 Re: Trouble with UTF-8 data
Previous Message Marko Kreen 2008-01-21 08:08:38 Re: [GENERAL] SHA1 on postgres 8.3