On Fri, 2010-01-15 at 13:26 -0700, James William Pye wrote: > 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?
I think both apply. This is great stuff, thank you for taking the effort. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
