On Wed, Feb 9, 2011 at 02:09, Jan Urbański <wulc...@wulczer.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*. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers