Re: plpython3

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.