Re: Array of composite types returned from python

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ronan Dunklau <ronan(dot)dunklau(at)dalibo(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Sim Zacks <sim(at)compulab(dot)co(dot)il>, ebehn(at)arinc(dot)com, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Array of composite types returned from python
Date: 2014-07-03 20:43:21
Message-ID: 1774.1404420201@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Ronan Dunklau <ronan(dot)dunklau(at)dalibo(dot)com> writes:
>> I don't know how to do that without implementing the cache itself.

> I don't either, but my thought was that we could hack up a simple
> one-element cache pretty trivially, eg static info and desc variables
> in PLyObject_ToComposite that are initialized the first time through.
> You could only test one composite-array type per session with that
> sort of kluge, but that would be good enough for doing some simple
> performance testing.

I did that, and found that building and returning a million-element
composite array took about 4.2 seconds without any optimization, and 3.2
seconds with the hacked-up cache (as of HEAD, asserts off). I'd say that
means we might want to do something about it eventually, but it's hardly
the first order of business.

I've committed the patch with a bit of additional cleanup. I credited
Ronan and Ed equally as authors, since I'd say the fix for plpy.prepare
was at least as complex as the original patch.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-07-03 21:05:32 Re: "RETURNING PRIMARY KEY" syntax extension
Previous Message Andrew Gierth 2014-07-03 20:34:09 Re: Aggregate function API versus grouping sets