Skip site navigation (1) Skip section navigation (2)

Re: plpython3 perf

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: James William Pye <lists(at)jwp(dot)name>
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 perf
Date: 2010-01-25 19:12:14
Message-ID: 1264446734.6089.56.camel@jd-desktop.unknown.charter.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 2010-01-20 at 19:32 -0700, James William Pye wrote:


> Apologies ahead of time for the lack pretty graphs. =)
> 
> I used two different builds/installations of PG to test as the PL names conflict. Both were compiled with the following CFLAGS(pg_config output):
> 
> -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
> 
> Both PLs were built against the same build of Python(recent svn update of release31-maint):
> 
> Python 3.1.1+ (release31-maint:77585M, Jan 17 2010, 10:29:13) 
> [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
> 

This is great stuff. Thanks for your diligence.


> I ran each of the test files a few times against the target installation, but I only attached one of each to this message. (Primarily, multiple runs to filter out any spurious spikes.)
> 
> The source SQL and output files are attached.
> 
> rawtest.sql.out is the output for raw data objects(native typing).
> pytypestest.sql.out is the output of the @pytypes test(native typing with conversion overhead).
> plpythontest.sql.out is the output for core's plpython(conversion).
> 
> A few samples from the output files are included inline below.
> 
> Each volatile function is called 100,000 times from a COUNT() aggregate, and the duration is measured using psql's \timing. Most of the functions simply return the first parameter given to it. The functions are ran inside a transaction because plpython3 does some cache clears(linecache) and GC at the end of transactions.
> 
> The parameter type, if any, is indicated by the label:
> 
> noparams:
> 
> 	raw: 125ms
> 	pytypes: 372ms (base overhead, it would appear)
> 	plpython: 309ms
> 
> oneint2:
> 
> 	raw: 140ms
>  	pytypes: 684ms
> 	plpython: 750ms
> 
> oneint8:
> 
> 	raw: 145ms
> 	pytypes: 676ms
> 	plpython: 718ms
> 
> text_large:
> 
> 	raw: 271ms
> 	pytypes: 2766ms
> 	plpython: 2310ms
> 
> composite:
> 
> 	raw: 235ms
> 	pytypes: 795ms (N/A, no conversion done, but takes a bit of a hit anyways)
> 	plpython: 1654ms
> 
> 


-- 
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.


In response to

pgsql-hackers by date

Next:From: Boszormenyi ZoltanDate: 2010-01-25 19:17:26
Subject: Re: ECPG patch 4.1, out-of-scope cursor support in native mode
Previous:From: Kevin GrittnerDate: 2010-01-25 19:06:54
Subject: Re: Largeobject Access Controls (r2460)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group