Re: copy vs. C function
| От | Tom Lane |
|---|---|
| Тема | Re: copy vs. C function |
| Дата | |
| Msg-id | 29057.1323843491@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: copy vs. C function (Jon Nelson <jnelson+pgsql@jamponi.net>) |
| Ответы |
Re: copy vs. C function
Re: copy vs. C function |
| Список | pgsql-performance |
Jon Nelson <jnelson+pgsql@jamponi.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
В списке pgsql-performance по дате отправления: