Re: pl/python refactoring

From: Jan Urbański <wulczer(at)wulczer(dot)org>
To: David Fetter <david(at)fetter(dot)org>
Cc: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pl/python refactoring
Date: 2011-01-19 16:07:19
Message-ID: 4D370C37.8030904@wulczer.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2011-01-19 16:18:38 Re: limiting hint bit I/O
Previous Message Simon Riggs 2011-01-19 16:05:05 Re: Re: [COMMITTERS] pgsql: Log replication connections only when log_connections is on