Re: [HACKERS] Why does plpython delay composite type resolution?

2016-12-21 Thread Jim Nasby
On 12/21/16 8:39 AM, Tom Lane wrote: Jim Nasby writes: On 12/21/16 1:55 AM, Andreas Karlsson wrote: Does your patch handle "ALTER TYPE name ADD ATTRIBUTE ..."? My immediate guess would be that it could be a cache invalidation thing. Won't that only happen at end

Re: [HACKERS] Why does plpython delay composite type resolution?

2016-12-21 Thread Tom Lane
Jim Nasby writes: > On 12/21/16 1:55 AM, Andreas Karlsson wrote: >> Does your patch handle "ALTER TYPE name ADD ATTRIBUTE ..."? My immediate >> guess would be that it could be a cache invalidation thing. > Won't that only happen at end of transaction? No.

Re: [HACKERS] Why does plpython delay composite type resolution?

2016-12-21 Thread Jim Nasby
On 12/21/16 1:55 AM, Andreas Karlsson wrote: On 12/21/2016 04:14 AM, Jim Nasby wrote: Why do functions that accept composite types delay type resolution until execution? I have a naive patch that speeds up plpy.execute() by 8% by caching interred python strings for the dictionary key names

Re: [HACKERS] Why does plpython delay composite type resolution?

2016-12-20 Thread Andreas Karlsson
On 12/21/2016 04:14 AM, Jim Nasby wrote: Why do functions that accept composite types delay type resolution until execution? I have a naive patch that speeds up plpy.execute() by 8% by caching interred python strings for the dictionary key names (which are repeated over and over). The next step

[HACKERS] Why does plpython delay composite type resolution?

2016-12-20 Thread Jim Nasby
Why do functions that accept composite types delay type resolution until execution? I have a naive patch that speeds up plpy.execute() by 8% by caching interred python strings for the dictionary key names (which are repeated over and over). The next step is to just pre-allocate those strings