Meldung mit &&

Hi,

ich bekomme die Meldung:

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));

Was spricht eigentlich dagegen, in der Doku einmal nachzulesen, ob der Syntax des SQL-Befehls richtig ist?



mfg

fristo

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))

Es ist ein Hinweis.

Aber nur scheint die nicht der optimale Weg der Abfrage zu sein oder es hängt mit der Indizierung zusammen

Hilft Dir [postgis-users] LWGEOM_gist_joinsel called with arguments that are not column references weiter?

Andreas

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!



mfg

fristo

Sorry, jetzt verstehe ich was der Fehler war. Hatte ein Brett vor dem Kopf :wink:

Das && raus und dafür ein = einsetzen behebt das ganze.

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.

Andreas

Jetzt bin ich neugierig:

  • selbes Resultat?
  • selber Plan?

Andreas

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 :wink: ) 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.

CU Uwe

Also ich würde gerne ein Ergbnis mit dem ‘=’ Vergleich hier ins Forum stellen, aber die Abfrage dauert mir zu lange :frowning:
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.

Wunderlich, ich hätte gedacht es müsste andersrum sein :confused:
Ein Vergleich wäre sicherlich interessant.

Gruß Uwe

Hallo Gisman, hallo Sauerkraut,

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.


mfg

fristo

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… :confused:

Schön Freitach noch

Uwe

Hallo Uwe,

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.


mfg

fristo