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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
