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  (idc danny <idcdanny@yahoo.com>)
Re: copy vs. C function  (Jon Nelson <jnelson+pgsql@jamponi.net>)
Список 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 по дате отправления:

Предыдущее
От: Mark Kirkwood
Дата:
Сообщение: Re: Slow query after upgrade from 8.2 to 8.4
Следующее
От: idc danny
Дата:
Сообщение: Re: copy vs. C function