Re: pl/python refactoring - Mailing list pgsql-hackers

From Jan Urbański
Subject Re: pl/python refactoring
Date
Msg-id 4D370C37.8030904@wulczer.org
Whole thread Raw
In response to Re: pl/python refactoring  (David Fetter <david@fetter.org>)
List pgsql-hackers
On 19/01/11 16:35, David Fetter wrote:
> On Wed, Jan 19, 2011 at 11:09:56AM +0100, Jan Urbański wrote:
>> On 19/01/11 02:06, Hitoshi Harada wrote:
>>> - PLy_(input|output)_tuple_funcs() in PLy_trigger_handler() is added.
>>> The comment says it should check for the possibility that the
>>> relation's tupdesc changed since last call. Is it true that tupdesc
>>> may change even in one statement? And it also says the two functions
>>> are responsible  for not doing repetitive work, but ISTM they are not
>>> doing something to stop redundant work. The function doesn't seem like
>>> lightweight enough to be called on each row.
>>
>> Hm, you may be right. I haven't touched that part of the code, but now
>> it seems to me that for triggers we do the I/O funcs lookup for every
>> row. I could try to check that and fix it, but not sure if I'll have the
>> time, and it's been that way before. Also, the CF is already closed in
>> theory...

I looked again and it seems that PLy_(input|output)_tuple_funcs does
indeed avoid repetitive work. Observe that in the loop going over the
TupleDesc attributes there's

if (arg->in.r.atts[i].typoid == desc->attrs[i]->atttypid)   continue;  /* already set up this entry */

which avoids the syscache lookup and calling PLy_input_datum_func2.

Cheers,
Jan


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Log replication connections only when log_connections is on
Next
From: Merlin Moncure
Date:
Subject: Re: limiting hint bit I/O