Actually, memunion does the opposite, it passes the resultant and preserves mem. The default behavior is fast-but-memory-hungry. And has been for some time, though in different forms. There were some bugs in the array handling code, but Mark CA killed most of them, so the latest 1.5 and 1.4 streams should be good. If it's possible that the issue is one of array size, maybe Mike could find the dial that controls that maximum, and turn it up and down and see if it makes his problem go away/happen sooner.
P. On Sat, Mar 20, 2010 at 7:41 AM, strk <s...@keybit.net> wrote: > On Sat, Mar 20, 2010 at 05:49:42AM -0400, Mike Leahy wrote: >> Hello again, >> >> It might be of interest to point out that substituting st_union() with >> st_memunion() seems to have worked around this. I'm curious though, because >> there is not a great deal of data being processed, and I am running this on a >> fairly sturdy system that that has more capacity than some of the Fedora >> systems I'm running. > > st_memunion builds a big array with all geometries in it.. > you were hitting a limit of the array type. > st_union should behave better. > > --strk; > > () Free GIS & Flash consultant/developer > /\ http://strk.keybit.net/services.html > _______________________________________________ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users > _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
