NOTICE: LWGEOM_gist_joinsel called with arguments that are not column references
wenn ich folgende Abfrage durchführe. Ich werde jetzt nicht ganz schlau daraus was damit gmemeint ist. Auf anderen Foren im Netz steht, dass man das igonieren kann, aber wie kann man das vermeiden oder optimieren?
Meine Abfrage ist:
select s1.gid from tab_streets as s1 inner join navteq_highway as s2 on
(startpoint(s1.the_geom) && endpoint(s2.the_geom));
Der Syntax ist soweit korrekt, der Befehl wird auch ausgeführt und das Ergebnis ist korrekt. Aber nur scheint die nicht der optimale Weg der Abfrage zu sein oder es hängt mit der Indizierung zusammen
Mein Explain ist folgender:
QUERY PLAN
Nested Loop (cost=0.00…15914.15 rows=6229 width=4)
-> Seq Scan on street s1 (cost=0.00…1192.95 rows=35295 width=36)
-> Index Scan using endpoint_t_gist on street s2 (cost=0.00…0.40 rows=1 width=32)
Index Cond: (startpoint(s1.the_geom) && endpoint(s2.the_geom))
Filter: (startpoint(s1.the_geom) && endpoint(s2.the_geom))
Du hast Recht, wenn man sich auf dem Standpunkt stellt, das man eine NOTICE von der Datenbank einfach ignorieren sollte. Und die NOTICE besagt doch, dass eine “column references” gefordert ist. Die Frage ist jetzt, wer hat Recht, die Datenbank mit der Meldung oder Du. Bevor du nochmals hier ein QUERY PLAN schickst, solltest Du besser den Syntax für den SQL-Befehl in der Doku nachlesen, insbesondere die ON-Klausel für den JOIN-Befehl. Der entspricht in dem SQL-Befehl nicht den Vorschriften!
Laaangsam. Hier ist PostGIS im Spiel. Das ‘&&’ ist ein PostGIS-Operator. Und eine NOTICE ist kein Fehler, nur ein Hinweis. Und für ON muß man nicht zwingend eine Column der beteiligten Tabellen nehmen:
test=*# select * from foo;
w
------------------
das ist ein test
bar
(2 rows)
test=*# select * from foo join foo f1 on(select 'true'::bool);
w | w
------------------+------------------
das ist ein test | das ist ein test
das ist ein test | bar
bar | das ist ein test
bar | bar
(4 rows)
Über Sinn und Unsinn kann man geteilter Meinung sein.
Aber:
Auch wenn ich von PostGIS keine Ahnung habe: Dein Gemotze ist für den Fragesteller offensichtlich nicht helfend. Zeig ihm doch, wie er die NOTICE wegbekommt.
Das ‘&&’ verschneidet die beiden Boundingboxes der Geometrien und liefert ein True, wenn sie sich überschneiden. In diesem Falle wurden Boundingboxen von Punkten verglichen, das geht wohl anscheinend, ist aber eher unsinnig, da es langsamer ist als der direkte Vergleich der Punkte. Es müssten ja erst aus jedem Punkt eine Boundingbox(4Punkte ) erzeugt werden und die dann miteinander verglichen werden (rel. teurer räumlicher Vergleich). So würde ich mir das zumindest erklären.
Angenehm, das PostGIS hier Bescheid sagt.
Also ich würde gerne ein Ergbnis mit dem ‘=’ Vergleich hier ins Forum stellen, aber die Abfrage dauert mir zu lange
Also im Kostenvergleich zeigt sich das der ‘&&’ dem ‘=’ wesentlich geschickter ist. Also wenn Interesse besteht kann ich auch gerne ein Explain mit den Kosten reinstellen.
Also ich hätte auch gedacht das der Bildvergleich aufwendiger ist.
der ‘&&’-Operator (Test Intersection) kann ohne weiteres, trotz der Meldung in form einer NOTICE, eingesetzt werden. Ursache für die Meldung ist, dass der ‘&&’-Operator im SQL-Parser der Datenbank nicht definiert ist. Normalerweise werden Testbedingungen als Ergebnis einer Funktion geliefert. Die ungewöhnlich Form für Test Intersection musste man wählen, da für die ON-Klausel ein “boolean_expression” vorgeschrieben ist.
Danke für die Erklärung. Was mich aber immer noch verwundert, ist die Tatsache, das der ‘geometrische’ Vergleich, der IMHO viel mehr overhead erzeugen müsste, schneller ist als der direkte Vergleich.
Ich müsste ja erst boundingboxen erzeugen und die verschneiden (was IMHO auch noch fehleranfällig ist, weil wenn sich die boundingboxen berühren, müssen sich die Elemente an sich noch lange nicht berühren).
Allerdings könnte sich das bei komplexen Geometrien in erster Näherung schon lohnen…grübel…
Diese Frage solltest Du den Entwicklern stellen, welche die Algorithmen implentiert haben. Die verwendete (GEOS-) Library ist ein Port der Java Topology Suite. Den Senior-Entwickler, Martin Davis, kann man auch direkt ansprechen. Die E-Mail-Adresse findest Du hier Contact: Martin Davis.