Re: Why does plpython delay composite type resolution?

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Andreas Karlsson <andreas(at)proxel(dot)se>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why does plpython delay composite type resolution?
Date: 2016-12-21 14:25:01
Message-ID: 83d693c8-84b7-33d5-aea2-35922bc43938@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 (which are
>> repeated over and over). The next step is to just pre-allocate those
>> strings as appropriate for the calling context, but it's not clear how
>> to handle that for input arguments.
>
> 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?

After reading the tuple queue code I'm wondering if part of the issue is
anonymous records, though that doesn't make much sense since plpython
doesn't support those.

Given the lackluster support for arrays and composites in plpython, I
suspect this is just a wart that hasn't been removed yet...
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-12-21 14:30:07 Re: Rethinking our fulltext phrase-search implementation
Previous Message Jim Nasby 2016-12-21 14:21:58 Re: Faster methods for getting SPI results