From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: copy vs. C function |
Date: | 2011-12-14 06:18:11 |
Message-ID: | 29057.1323843491@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> writes:
> The only thing I have left are these statements:
> get_call_result_type
> TupleDescGetAttInMetadata
> BuildTupleFromCStrings
> HeapTupleGetDatum
> and finally PG_RETURN_DATUM
> It turns out that:
> get_call_result_type adds 43 seconds [total: 54],
> TupleDescGetAttInMetadata adds 19 seconds [total: 73],
> BuildTypleFromCStrings accounts for 43 seconds [total: 116].
> So those three functions account for 90% of the total time spent.
> What alternatives exist? Do I have to call get_call_result_type /every
> time/ through the function?
Well, if you're concerned about performance then I think you're going
about this in entirely the wrong way, because as far as I can tell from
this you're converting all the field values to text and back again.
You should be trying to keep the values in Datum format and then
invoking heap_form_tuple. And yeah, you probably could cache the
type information across calls.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | idc danny | 2011-12-14 07:02:10 | Re: copy vs. C function |
Previous Message | Mark Kirkwood | 2011-12-13 22:13:03 | Re: Slow query after upgrade from 8.2 to 8.4 |