<div dir="ltr"><div><div><div><div>A while ago I would really have appreciated an easy way to visualize index.<br><br></div>It is useful to explain how it works, illustrate, understand, etc.<br><br></div>After all what make PostGIS truly unique is the combination of reliable geometry operation with very powerful index and data-oriented language (SQL).<br><br></div>Cheers,<br></div>Rémi-C<br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-03 9:58 GMT+01:00 Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Mar 02, 2015 at 10:57:29AM -0800, Paul Ramsey wrote:<br>
> Yes, I think the n-d index is still ang-tan.<br>
> Oleg and Teodor's site had some code for visualizing r-tree boxes that<br>
> could maybe be used to get a feel? Doing higher dimensions is going to<br>
> be difficut, I would imagine.<br>
<br>
</span>I got Oleg and Teodor's "Gevel" in place, great tool!<br>
Now the problem is that we hide so much our index types under the carpet<br>
that converting index keys to geometries is not easy.<br>
<br>
Not only BOX2DF type lacks a cast to GEOMETRY but does not even implement<br>
text output, so there's basically no way to get it printed.<br>
Hadn't tried yet, but I guess the same holds for GIDX.<br>
<br>
Do you guys have an problem with me implementing the casts ?<br>
<br>
--strk;<br>
<div class="HOEnZb"><div class="h5"><br>
> On Mon, Mar 2, 2015 at 10:54 AM, Sandro Santilli <<a href="mailto:strk@keybit.net">strk@keybit.net</a>> wrote:<br>
> > I'm running performance tests with n-dimensional data and<br>
> > found cases in which fetching 5 points out of ~35 million<br>
> > can take 20K reads _or_ 2K reads depending on whether the<br>
> > Z/M selectivity is higher or the 2d selectivity is.<br>
> ><br>
> > In other words, if the query box is large but "low" it takes<br>
> > 10 times more seeking than if it is narrow but tall.<br>
> ><br>
> > I guess this has to do with the way splits were choosen and of<br>
> > course to the distribution of the data. To know more about the<br>
> > case I'd like to be able to "see" the index volumes in some way.<br>
> ><br>
> > Do you have ideas about how to visualize contents of the index ?<br>
> > I remember someone did it a long time ago.<br>
> ><br>
> > Another though is that the 2d index was changed 2 years ago<br>
> > to use Korotkov ( double-sorting ) approach for splitting, whereas the<br>
> > nd seems to be still using Ang-Tan one, is that correct ?<br>
> ><br>
> > REF: <a href="http://en.wikipedia.org/wiki/R-tree" target="_blank">http://en.wikipedia.org/wiki/R-tree</a><br>
> >      <a href="http://trac.osgeo.org/postgis/ticket/1895" target="_blank">http://trac.osgeo.org/postgis/ticket/1895</a><br>
> ><br>
> > --strk;<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</a><br>
</div></div></blockquote></div><br></div>