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
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 |