From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
Cc: | James Mansion <james(at)mansionfamily(dot)plus(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Szymon Guz <mabewlun(at)gmail(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plpython implementation |
Date: | 2013-07-01 06:36:56 |
Message-ID: | 51D12388.1060603@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07/01/2013 07:53 AM, Claudio Freire wrote:
> On Mon, Jul 1, 2013 at 2:29 AM, james <james(at)mansionfamily(dot)plus(dot)com> wrote:
>> On 01/07/2013 02:43, Claudio Freire wrote:
>>> In essence, you'd have to use another implementation. CPython guys
>>> have left it very clear they don't intend to "fix" that, as they don't
>>> consider it a bug. It's just how it is.
>> Given how useful it is to have a scripting language that can be used outside
>> of the database as well as inside it, would it be reasonable to consider
>> 'promoting' pllua?
>>
>> My understanding is that it (lua) is much cleaner under the hood (than
>> CPython).
>> Although I do recognise that Python as a whole has always had more traction.
> Well, that, or you can use another implementation. There are many, and
> PyPy should be seriously considered given its JIT and how much faster
> it is for raw computation power, which is what a DB is most likely
> going to care about.
OTOH, pypy startup time is bigger than CPython. It is also generally
slower at running small on-call functions before JIT kicks in.
> I bet PyPy's sandboxing is a lot better as well.
pypy sandbox implementation seems to be a sound one, as it
delegates all "unsafe" operations to outside controller at bytecode
level. The outside controller usually being a standard CPython wrapper.
Of course this makes any such operations slower, but this is the price
to pay for sandboxing.
> Making a postgres-interphasing pypy fork I guess would be a nice
> project, it's as "simple" as implementing all of plpy's API in RPython
> and translating a C module out of it.
I have some ideas about allowing new pl-s to be written in pl/pythonu
If any of you interested in this are at Europython come talk to me about
this after my presentations ;)
> No, I'm not volunteering ;-)
Neither am I, at least not yet
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2013-07-01 06:58:17 | Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls |
Previous Message | Pavel Stehule | 2013-07-01 06:35:44 | Re: Review: query result history in psql |