<div dir="ltr"><div><div><div><div><div>OK,<br>I ended looking for every instance of "containing_face" in the topology.sql file in postgres extension<br><br></div>Note that i found <br>"  -- TODO: consider also adding an index on node.containing_face "<br>

<br></div>The index would be used in <br>_the "intersects" function (case of point/polygon) "'WHERE  ... AND r2.element_id = n.containing_face" '"<br></div>_the addface function ''WHERE containing_face IS NOT NULL"<br>

</div>_ the ST_RemEdgeNewFace function "    -- Update containing_face for all nodes still referencing old faces"<br>_the ST_RemEdgeModFace function "    -- Update containing_face for all nodes still referencing old faces"<br>

</div>_ the _ST_AddFaceSplit function "  -- Update isolated nodes in new new face "<br><div><br><br></div><div>I think there is significant evidence that such an index will be used.<br></div><div>My usage of topology is very limited (I only use edge topo) and I don't have the benchmark to prove that such index would speed the operations.<br>
</div><div>If somebody uses face/node, it should be simple to benchmark : drop topology, create topology, create index, import data in topology .<br></div><div>Then a simple look on index stats should tell if it was used ans how much.<br>
</div><div><br>However :<br></div><div>_the above function will obviously be speeded. <br></div><div>_index are mandatory on primary key (postgres default), this should be the same for "simple" foreign key <br></div>
<div>_ the basic btree index is very low cost (time & memory)<br><br></div><div>About putting/removing indexes and constraint,<br></div><div>I think your right about trigger/constraint in one case : a batch topology import.<br>
</div><div>I fear the changes to do so efficiently would be important (more or less rewrite every function the batch way, and of course disable all triggers/check) .<br><br></div>I feel disabling index, filling table, then computing indexes is the kind of optimization that we are far far from needing. Maybe when data import would be in the speed range of grass data import, thats a 100 factor to gain before such optimization.<br>
<br><div>Cheers,<br>Rémi-C<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-29 16:28 GMT+02: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"><div class="HOEnZb"><div class="h5">On Tue, Jul 29, 2014 at 01:23:31PM +0200, Rémi Cura wrote:<br>
> Hey,<br>
> it seems there is no index on<br>
> node.containing_face in a classical topology schema.<br>
><br>
> Is there a special reason to do so ?<br>
> On my sample data (about 25k node, 30 k edge), using such an index (`CREATE<br>
> INDEX ON bdtopo_topological.node (containing_face)`) make looking for a<br>
> containing_face going from 15ms to 0.5 ms (30 times faster).<br>
<br>
</div></div>There's no strict policy about what indexes are created by CreateTopology.<br>
I think I've recently added creation of some indexes when they've been<br>
found useful for topology construction.<br>
<br>
I guess a rule of thumb could be to check if any core function would benefit<br>
from having an index. Not sure if any existing function queries points within<br>
a face. Can you check ?<br>
<br>
Can you also check the effect of having indexes defined on topology<br>
construction performance ? We should maybe have management functions<br>
to add/remove indexes/constraints based on topology state (construction,<br>
usage).<br>
<br>
--strk;<br>
<br>
 ()  ASCII ribbon campaign  --  Keep it simple !<br>
 /\  <a href="http://strk.keybit.net/rants/ascii_mails.txt" target="_blank">http://strk.keybit.net/rants/ascii_mails.txt</a><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>
</blockquote></div><br></div>