Pierre,<br><br>+1 <br><br>As for the penalty, you are correct: the penalty appears to be caused by casting the integers to float values in the expression.<br><br>-Zwarg<br><br><div class="gmail_quote">On Fri, Feb 10, 2012 at 9:38 AM, Pierre Racine <span dir="ltr"><<a href="mailto:Pierre.Racine@sbf.ulaval.ca">Pierre.Racine@sbf.ulaval.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It is true that passing the x and y might be usefull in some cases but it is kind of a luxury.<br>
<br>
If I can give my two cents I would suggest:<br>
<br>
-we come back to the float so we don't penalize most applications. I guess the only penalty to the one using the x and y is to cast the float to integer in the expression. Right? <br></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-we fill a ticket expecting some input from PostgreSQL people (robe or a some inquiry on their list)<br>
<br>
-we fix/wontfix the ticket depending on the info we get.<br>
<span class="HOEnZb"><font color="#888888"><br>
Pierre<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> -----Original Message-----<br>
> From: <a href="mailto:postgis-devel-bounces@postgis.refractions.net">postgis-devel-bounces@postgis.refractions.net</a> [mailto:<a href="mailto:postgis-devel-">postgis-devel-</a><br>
> <a href="mailto:bounces@postgis.refractions.net">bounces@postgis.refractions.net</a>] On Behalf Of dustymugs<br>
> Sent: Thursday, February 09, 2012 7:32 PM<br>
> To: <a href="mailto:postgis-devel@postgis.refractions.net">postgis-devel@postgis.refractions.net</a><br>
> Subject: Re: [postgis-devel] Regression performance.<br>
><br>
> Well, please do come to a consensus. Once that is achieved, I'll make any<br>
> changes that need to be made to the 2-raster variants.<br>
><br>
> -bborie<br>
><br>
> On 02/09/2012 04:14 PM, David Zwarg wrote:<br>
> > I see your point about #1557, but I disagree.<br>
> ><br>
> > I believe that we should aim for the best performance out of the<br>
> > raster MapAlgebra routines in any way possible. It may be inconvenient<br>
> > for calling functions, but if you really need those values, you may<br>
> > always do "[rast.x]::integer". It is a little messier, but I believe<br>
> > that it's an acceptable inconvenience: no data is lost converting the<br>
> > raster x or y coordinate from float8 to int32, and only if you need it<br>
> > will you incur the penalty of casting to an integer.<br>
> ><br>
> > Unfortunately, that is exactly the situation you seem to be<br>
> > experiencing, strk, but I believe that it would be a mistake to<br>
> > penalize all callers of ST_MapAlgebraExpr for this overhead, versus<br>
> > the rare (we *just* introduced the x& y parameters) case when you<br>
> > need the x and y parameters inside of the cell processing expression.<br>
> ><br>
> > A note on the surprising factor: it took myself and David Bronough at<br>
> > the code sprint all day to profile and identify what was happening.<br>
> > Both of us were looking at the patch from r9112, scratching our heads.<br>
> > The removal of strstr should have made it faster, but it turns out the<br>
> > use of integers in the expressions were doing something in the<br>
> > parser/planner/evaluator for every pixel, and this was slowing<br>
> > everything down. It doesn't make sense on many levels, and I would<br>
> > have thought that integer math would be faster that floating point<br>
> > math, but in this case it is not the case. Something in the way<br>
> > postgres evaluates that parameterized query changes that assumption, which I<br>
> have no knowledge of (thus the mystery for me).<br>
> ><br>
> > Thanks,<br>
> > Zwarg<br>
> ><br>
> > On Thu, Feb 9, 2012 at 12:47 PM, Sandro Santilli<<a href="mailto:strk@keybit.net">strk@keybit.net</a>> wrote:<br>
> ><br>
> >> On Thu, Feb 09, 2012 at 12:20:45PM -0800, David Zwarg wrote:<br>
> >>> Hello,<br>
> >>><br>
> >>> I was profiling the performance of the changes that happened in<br>
> >>> r9112,<br>
> >> and<br>
> >>> it turned out to be very significant to pass and evaluate integers<br>
> >>> in the prepared expression. Sticking with float8 values for the x<br>
> >>> and y<br>
> >> positions<br>
> >>> of the pixel contain significant performance benefits (although<br>
> >>> counter-intuitive).<br>
> >>><br>
> >>> I've changed the x and y positions in 1 raster map algebra back to<br>
> >>> float values for performance reasons.<br>
> >>><br>
> >>> These are my metrics for running 5 sets of 10 rasters, each 500x500<br>
> >> pixels,<br>
> >>> from one of the SRTM tiles linked to by the WKTRaster tutorial page.<br>
> >> Times<br>
> >>> are in milliseconds. The first column is revision 9112 (removal of<br>
> >>> strstr in the pixel loop, using integer as x and y pixel values),<br>
> >>> the second column is that same revision (with a modification to use<br>
> >>> float8 instead<br>
> >> of<br>
> >>> int32 for x and y pixel coordinates), the third column is revision<br>
> >>> 9111 (using strstr in the pixel loop), the fourth column is the<br>
> >>> incorporation<br>
> >> of<br>
> >>> this change into the HEAD revision as of this morning (more memory<br>
> >>> allocations have been moved out of the pixel loop).<br>
> >><br>
> >> The numbers for those like me not willing to fire a graphical browser:<br>
> >><br>
> >> r9112 r9112-int r9111 r9137<br>
> >> ----------------------------------------------------------<br>
> >> 9839.746 8473.403 9094.589 7820.646<br>
> >> 6228.067 5329.813 5763.88 4738.372<br>
> >> 8749.516 7441.936 7893.893 6866.745<br>
> >> 13618.762 11254.392 12177.314 10780.401<br>
> >> 6233.851 5442.746 5730.231 4767.192<br>
> >><br>
> >> I'm really surprised. Which version of PostgreSQL were you using ?<br>
> >> I'm still not convinced we should pretend numbers are float though.<br>
> >> It was changed back for a reason:<br>
> >> <a href="http://trac.osgeo.org/postgis/ticket/1557" target="_blank">http://trac.osgeo.org/postgis/ticket/1557</a><br>
> >><br>
> >> --strk;<br>
> >><br>
> >> ,------o-.<br>
> >> | __/ | Delivering high quality PostGIS 2.0 !<br>
> >> | / 2.0 | <a href="http://strk.keybit.net" target="_blank">http://strk.keybit.net</a><br>
> >> `-o------'<br>
> >><br>
> >> _______________________________________________<br>
> >> postgis-devel mailing list<br>
> >> <a href="mailto:postgis-devel@postgis.refractions.net">postgis-devel@postgis.refractions.net</a><br>
> >> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>
> >><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > postgis-devel mailing list<br>
> > <a href="mailto:postgis-devel@postgis.refractions.net">postgis-devel@postgis.refractions.net</a><br>
> > <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>
> _______________________________________________<br>
> postgis-devel mailing list<br>
> <a href="mailto:postgis-devel@postgis.refractions.net">postgis-devel@postgis.refractions.net</a><br>
> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@postgis.refractions.net">postgis-devel@postgis.refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>
</div></div></blockquote></div><br>