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

Re: plpgsql function is so slow

From: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql function is so slow
Date: 2009-09-25 03:49:46
Message-ID: 4ABC3DDA.8030709@timbira.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane escreveu:
> FWIW, the high showing of AllocSetReset in your profile suggests to me
> that you're timing an assert-enabled build, which wouldn't exactly be
> a fair comparison to an Oracle production build anyhow.
> 
Ops... forgot to remove it from other test. It seems much better but far from
the ideal. :( I've never taken a look at the pl/pgsql code but it could be
nice if there would be two path codes: access-data and non-access-data paths.
I have no idea if it will be possible (is path type too complex to detect?)
but it will certainly improve the non-access-data functions.

euler=# select function1();  -- PL/PgSQL
 function1
-----------
 100000000
(1 row)

Time: 34455,263 ms
euler=# select function3();  -- PL/Perl
 function3
-----------
 100000000
(1 row)

Time: 24986,016 ms

pl/pgsql oprofile is:

samples  %        symbol name
620      14.4961  ExecMakeFunctionResultNoSets
537      12.5555  AllocSetAlloc
484      11.3163  AllocSetReset
323       7.5520  RevalidateCachedPlan
292       6.8272  ExecEvalParam
222       5.1906  pgstat_init_function_usage
218       5.0970  int4pl
199       4.6528  ResourceOwnerForgetPlanCacheRef
196       4.5827  AcquireExecutorLocks
175       4.0917  ResourceOwnerRememberPlanCacheRef
166       3.8812  ReleaseCachedPlan
155       3.6240  pgstat_end_function_usage
143       3.3435  check_stack_depth
136       3.1798  ExecEvalConst
123       2.8758  ResourceOwnerEnlargePlanCacheRefs
100       2.3381  MemoryContextReset
99        2.3147  MemoryContextAlloc
48        1.1223  SPI_pop
41        0.9586  SPI_push


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/


In response to

Responses

pgsql-hackers by date

Next:From: David E. WheelerDate: 2009-09-25 04:52:34
Subject: Re: latest hstore patch
Previous:From: Robert HaasDate: 2009-09-25 03:18:27
Subject: Re: WIP - syslogger infrastructure changes

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