Re: Array of composite types returned from python - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Array of composite types returned from python
Date
Msg-id 1774.1404420201@sss.pgh.pa.us
Whole thread Raw
In response to Re: Array of composite types returned from python  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> Ronan Dunklau <ronan.dunklau@dalibo.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



pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Aggregate function API versus grouping sets
Next
From: Tom Lane
Date:
Subject: Re: "RETURNING PRIMARY KEY" syntax extension