From: | James William Pye <lists(at)jwp(dot)name> |
---|---|
To: | jd(at)commandprompt(dot)com |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plpython3 |
Date: | 2010-01-15 20:26:13 |
Message-ID: | AEA4768C-62D3-4B3A-8005-283C8F7748F5@jwp.name |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jan 14, 2010, at 2:03 PM, Joshua D. Drake wrote:
> What I would (as a non hacker) would look for is:
>
> (1) Generalized benchmarks between plpython(core) and plpython3u
>
> I know a lot of these are subjective, but it is still good to see if
> there are any curves or points that bring the performance of either to
> light.
I guess I could do some simple function I/O tests to identify invocation overhead(take a single parameter and return it). This should give a somewhat reasonable view of the trade-offs of "native typing" vs conversion performance-wise. One thing to keep in mind is that *three* tests would need to be done per parameter set:
1. plpython's
2. plpython3's (raw data objects/"native typing")
3. plpython3's + @pytypes
The third should show degraded performance in comparison to plpythonu's whereas the second should show improvement or near equivalence.
@pytypes is actually implemented in pure-Python, so the impact should be quite visible.
http://python.projects.postgresql.org/pldocs/plpython3-postgres-pytypes.html
I'm not sure there's anything else worth measuring. SRFs, maybe?
> (2) Example of the traceback facility, I know it is silly but I don't
> have time to actually download head, apply the patch and test this.
Well, if you ever do find some time, the *easiest* way would probably be to download a branch snapshot from git.pg.org:
http://git.postgresql.org/gitweb?p=plpython3.git;a=snapshot;h=refs/heads/plpython3;sf=tgz
It requires Python 3.1. 3.0 has been abandoned by python.org.
> This
> type of thing, showing debugging facilities within the function would be
> killer.
The test output has a *lot* of tracebacks, so I'll just copy and paste one here.
This one shows the traceback output of a chained exception.
-- suffocates a pg error, and attempts to enter a protected area
CREATE OR REPLACE FUNCTION pg_failure_suf_IFTE() RETURNS VOID LANGUAGE plpython3u AS
$python$
import Postgres
rp = Postgres.Type(Postgres.CONST['REGPROCEDUREOID'])
def main():
try:
fun = rp('nosuchfunc(int17,zzz)')
except:
# Should be valid, but the protection of
# PL_DB_IN_ERROR should keep it from getting called.
rp('pg_x_failure_suf()')
$python$;
SELECT pg_failure_suf_IFTE();
ERROR: database action attempted while in failed transaction
CONTEXT: [exception from Python]
Traceback (most recent call last):
File "public.pg_failure_suf_ifte()", line 8, in main
fun = rp('nosuchfunc(int17,zzz)')
Postgres.Exception: type "int17" does not exist
CODE: 42704
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "public.pg_failure_suf_ifte()", line 12, in main
rp('pg_x_failure_suf()')
Postgres.Exception
[public.pg_failure_suf_ifte()]
> (3) A distinct real world comparison where the core plpython falls down
> (if it does) against the plpython3u implementation
Hrm. Are you looking for something that plpython3 can do that plpython can't? Or are you looking for something where plpython makes the user work a lot harder?
From | Date | Subject | |
---|---|---|---|
Next Message | Aidan Van Dyk | 2010-01-15 20:27:10 | Re: Streaming replication and non-blocking I/O |
Previous Message | Tom Lane | 2010-01-15 20:25:08 | Re: Streaming replication and non-blocking I/O |