Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 72F16EEA155 for ; Wed, 14 Dec 2011 02:18:40 -0400 (AST) Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RaiAb-0006lk-Ni for pgsql-performance@postgresql.org; Wed, 14 Dec 2011 06:18:40 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id pBE6ICEh029058; Wed, 14 Dec 2011 01:18:12 -0500 (EST) To: Jon Nelson cc: pgsql-performance@postgresql.org Subject: Re: copy vs. C function In-reply-to: References: Comments: In-reply-to Jon Nelson message dated "Tue, 13 Dec 2011 08:29:52 -0600" Date: Wed, 14 Dec 2011 01:18:11 -0500 Message-ID: <29057.1323843491@sss.pgh.pa.us> From: Tom Lane X-Pg-Spam-Score: -4.2 (----) X-Archive-Number: 201112/106 X-Sequence-Number: 45905 Jon Nelson 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