From: | Alex Hunsaker <badalex(at)gmail(dot)com> |
---|---|
To: | Jan Urbański <wulczer(at)wulczer(dot)org> |
Cc: | Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pl/python invalidate functions with composite arguments |
Date: | 2011-02-11 02:06:06 |
Message-ID: | AANLkTinqO-P_RApy_q3XMaspC0NayqiZhOZHXQFgdJvy@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 9, 2011 at 02:09, Jan Urbański <wulczer(at)wulczer(dot)org> wrote:
> On 27/01/11 22:42, Jan Urbański wrote:
>> On 23/12/10 14:50, Jan Urbański wrote:
>>> Here's a patch implementing properly invalidating functions that have
>>> composite type arguments after the type changes, as mentioned in
>>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
>>> an incremental patch on top of the plpython-refactor patch sent eariler.
>>
>> Updated to master.
>
> Again.
Looks good, it works as described, the code is clean and well
documented and it passes the added regression tests.
I took the liberty of looking at the other pls to see how they handled
this to find they don't cache them in the first place. For fun, I
hacked plpython to not cache to see if there was any performance
difference pre patch, post patch and in the non-cached cases. I
couldn't find any probably due to:
1) my simple test case (select
count(test_composite_table_input('(John, 100, "(10)")')) FROM
generate_series(1, 1000000);)
2) things being cached
3) cache invalidation having to do most of the work that the non
caching cache does. I think there is one or two more SearchSysCall's.
4) overhead from cassert
It seems a bit heavy handed to invalidate and remake the entire
plpython function whenever we hit this case. I think we could get away
with setting ->is_rowtype = 2 in PLy_procedure_valid() instead. I
suppose it should be fairly rare case anyway so... *shrug*.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2011-02-11 02:27:30 | Re: [PERFORM] pgbench to the MAXINT |
Previous Message | Alex Hunsaker | 2011-02-11 01:28:24 | Re: Careful PL/Perl Release Not Required |