2013/11/25 Tom Lane <t...@sss.pgh.pa.us> > Heikki Linnakangas <hei...@localhost.vmware.com> writes: > > In general, I'm not convinced this patch is worth the trouble. The > > speedup isn't all that great; manipulating large arrays in PL/pgSQL is > > still so slow that if you care about performance you'll want to rewrite > > your function in some other language or use temporary tables. And you > > only get a gain with arrays of fixed-length element type with no NULLs. > > > So I think we should drop this patch in its current form. If we want to > > make array manipulation in PL/pgSQL, I think we'll have to do something > > similar to how we handle "row" variables, or something else entirely. > > I think that this area would be a fruitful place to make use of the > noncontiguous datatype storage ideas that we were discussing with the > PostGIS guys recently. I agree that tackling it in the context of plpgsql > alone is not a good way to go at it. > > I'm not saying this in a vacuum of information, either. Some of the guys > at Salesforce have been poking at noncontiguous storage for arrays and > have gotten nice speedups --- but their patch is for plpgsql only and > only addresses arrays, which makes it enough of a kluge that I've not > wanted to bring it to the community. I think we should work towards > a general solution instead. >
I am for general solution (because these issues are good performance traps), but a early particular solution can be valuable for lot of users too - mainly if general solution can carry in two, three years horizon Regards Pavel > > regards, tom lane >
