Re: hexadecimal to decimal - Mailing list pgsql-general
| From | Joe Conway | 
|---|---|
| Subject | Re: hexadecimal to decimal | 
| Date | |
| Msg-id | 3F28A759.9030400@joeconway.com Whole thread Raw | 
| In response to | Re: hexadecimal to decimal (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Responses | Re: hexadecimal to decimal | 
| List | pgsql-general | 
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>>I tried that after I posted, but only saw roughly 30% improvement (which
>>is consistent with my earlier tests IIRC). Not bad, but this still left
>>plperl initial call at ~40 msec versus plpgsql at ~4 msec.
>
> Hm.  And the first call to a plpgsql function does require opening a
> shared library.  Curious that libperl seems so much more heavyweight
> than plpgsql.
>
I found the problem (or arguably two). Hows this look from a fresh psql
session:
regression=# explain analyze select hex_to_int(f1) from foo;
                                           QUERY PLAN
-----------------------------------------------------------------------------------------------
  Seq Scan on foo  (cost=0.00..22.50 rows=1000 width=6) (actual
time=3.31..3.53 rows=3 loops=1)
  Total runtime: 3.69 msec
(2 rows)
regression=# explain analyze select hex_to_int_perl('ff');
                                     QUERY PLAN
----------------------------------------------------------------------------------
  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=2.38..2.39
rows=1 loops=1)
  Total runtime: 2.43 msec
(2 rows)
regression=# explain analyze select hex_to_int(f1) from foo;
                                           QUERY PLAN
-----------------------------------------------------------------------------------------------
  Seq Scan on foo  (cost=0.00..22.50 rows=1000 width=6) (actual
time=0.29..0.49 rows=3 loops=1)
  Total runtime: 0.54 msec
(2 rows)
regression=# explain analyze select hex_to_int_perl('ff');
                                     QUERY PLAN
----------------------------------------------------------------------------------
  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.15..0.15
rows=1 loops=1)
  Total runtime: 0.18 msec
(2 rows)
Now the first call to the perl function is quicker than plpgsql and 90+%
faster than without preloading :-)
The first problem is that the initialization function for plperl,
plperl_init_all() is declared static, hence it couldn't be loaded
externally at all. The second problem is that when I wrote
process_preload_libraries() I used this line to call the init function:
   initfunc = (func_ptr) load_external_function(filename, funcname,
                                                    false, NULL);
That false means that load_external_function() doesn't report errors if
the funcname cannot be found ;(
My reasoning at the time was that library preloading shouldn't prevent
the postmaster from starting, even if it is unsuccessful, but now I
wonder if that was a good idea.
What do you think:
1) should that call to load_external_function() use true for signalNotFound?
2) do you want a patch that exports plperl_init_all() (and I guess
similar init functions in pltcl and plpython)?
Joe
		
	pgsql-general by date: