<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18783"></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=015400718-19072009><FONT color=#0000ff
size=2 face=Arial>Windowing functions come in especially handy for nearest
neighbor search getting top n per location. We are going to demonstrate
that in our OSCON conference. Slides and materials will of course will be
available after the conference is over.</FONT></SPAN></DIV><BR>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B>
postgis-devel-bounces@postgis.refractions.net
[mailto:postgis-devel-bounces@postgis.refractions.net] <B>On Behalf Of
</B>nicklas.aven@jordogskog.no<BR><B>Sent:</B> Sunday, July 19, 2009 1:52
PM<BR><B>To:</B> PostGIS Development Discussion<BR><B>Subject:</B> Re:
[postgis-devel] Caching function calls with CTEs<BR></FONT><BR></DIV>
<DIV></DIV>This is really cool Regina and Leo<BR><BR>It's a new way of thinking
for me to to use this recursive thing, but I can see that it is very
useful.<BR>I hope I will get some time in the near future to try to understand
it better.<BR><BR>Also the windowing functions together with postgis aggregate
function will be fun to try.<BR><BR>/Nicklas<BR><BR><BR><BR><BR><BR>2009-07-17
Paragon Corporation wrote:<BR><BR>Nicklas,<BR>><BR>>We tried CTEs against
that annoying issue of functions not being cached in<BR>>the same row.
Preliminary tests seem to suggest it might be the ideal<BR>>solution for
this.<BR>>We suspect it will also be good in many other scenarios where the
planner<BR>>refuses to use indexes in the right order
etc.<BR>><BR>>http://www.postgresonline.com/journal/index.php?/archives/127-guid.html<BR>><BR>>We
are going to test with real spatial queries next in preparation for
our<BR>>OSCON presentation next
week.<BR>><BR>>http://en.oreilly.com/oscon2009/public/schedule/detail/7859<BR>>Sadly
it looks like we probably won't have 1.4 out in time for our<BR>>presentation
- oh well :(<BR>><BR>><BR>>Anyrate take a look and test with your data
to see if it speeds up your<BR>>queries.<BR>><BR>>L &
R<BR>><BR>><BR>>_______________________________________________<BR>>postgis-devel
mailing
list<BR>>postgis-devel@postgis.refractions.net<BR>>http://postgis.refractions.net/mailman/listinfo/postgis-devel<BR>><BR>>
</BODY></HTML>