<div dir="ltr"><div><div><div>Hey Arnaud,<br></div>thanks for this good idea.<br><br></div>I hadn't thought of that!<br></div><div>I really like the concept of reading more or less data to get more or less precision, I used it for point cloud Level of Details.<br></div><div><br></div><div>Indeed it could be used in partiton check.<br><br></div><div>We would still have the limit that the geohash used to filter stuff would need to be hard written in the query (like using a bbox or other geometry type)<br><br></div><div>Cheers,<br></div><div>Rémi-C<br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-03 11:50 GMT+02:00 Arnaud Lesauvage <span dir="ltr"><<a href="mailto:arnaud.listes@codata.eu" target="_blank">arnaud.listes@codata.eu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Rémi,<br>
have you taken a look at ST_GeoHash ?<br>
It might be a good candidate for your constraint exclusion check.<br>
There are restrictions though. Coordinates must be in lat/lon for instance.<br>
<a href="http://postgis.net/docs/ST_GeoHash.html" target="_blank">http://postgis.net/docs/ST_<u></u>GeoHash.html</a><span class="HOEnZb"><font color="#888888"><br>
<br>
Arnaud</font></span><span class="im HOEnZb"><br>
<br>
Le 3/04/2015 10:49, Rémi Cura a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now postgres offers partitioning, that is that you build a hierarchy of<br>
tables.<br>
<br>
In this case, you would have one empty father table, and all the<br>
thousand table would be declared as child of the father table.<br>
Now when you write<br>
select * from father;<br>
you query in fact all the child tables.<br>
<br>
This is all good and working, but it will be inefficient, because each<br>
time you look for geometry within a rectangle, you would have to read<br>
all tables (using their index).<br>
Of course having thousands of indexes in memory is not possible, so it<br>
would be very slow.<br>
<br>
Postgres offers a solution for that, which is to declare constraints<br>
(check) on table.<br>
<br>
So you would say, table child_1 is entirely contained in a rectangle R1,<br>
table child_2 entirely contained in a rectangle R2, etc.<br>
<br>
That way, when you query the father table and asking all the geometry<br>
inside a rectangle R0,<br>
the planner will first check in which tables i Ri intersects R0,<br>
then it will only consider those tables, instead of considering all the<br>
tables.<br>
<br>
This is the theory. In practice the planner was not using those<br>
constraints (check).<br>
</blockquote>
<br>
<br>
<br></span><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-<u></u>bin/mailman/listinfo/postgis-<u></u>users</a><br>
</div></div></blockquote></div><br></div>