SDO_DISTANCE - About its performance

Question

Hi, I'm using SDO_DISTANCE in order to obtain the minimum distance between the geometries (polygons) stored in some table. The results are OK but the performance isn't: it takes up to 3 minutes to compute the minimum distance between two of the geometries... while the equivalent PostGIS function with the same data takes only 3 or 4 seconds.
This is the query I'm running:
SELECT
     SDO_GEOM.SDO_DISTANCE(t1.geom, t2.geom, 0.05) as distance
FROM
     mytable t1,
     mytable t2
WHERE
     t1.id = 1 AND
     t2.id = 2;Am I doing something wrong? Thanks!

Answer 1

Dante777,
I looked at your original posting and decided I wouldn't waste the time trying to respond as there just wasn't anything in your posting that I could use to solve your problem.
Follow this:
Hi, I'm using SDO_DISTANCE in order to obtain the minimum distance between the geometries (polygons) stored in some table.You then provide a SQL statement:
SELECT
     SDO_GEOM.SDO_DISTANCE(t1.geom, t2.geom, 0.05) as distance
FROM
     mytable t1,
     mytable t2
WHERE
     t1.id = 1 AND
     t2.id = 2;And then:
Am I doing something wrong?Well, yes you are but it is not what you think.
You simply don't supply any decent information to the hard working people who want to try to help you.
Firstly you forgot to ask:
ID columns have an index right?To whit you answer:
That table has only a spatial index,
How many records do the tables have?To whit you answer:
with only 17 records I don't think it needs more than that.So, you don't answer a direct question about an attribute index rather we have to infer it from the new fact that it has a spatial index (which most users know is irrelevant to sdo_distance's operation) and only 17 records. That is, if it has only "17 records" why do I need an attribute index?
Then you give us some good information that should have been provided up front:
The geometries are quite complex (they have thousands of vertices), but still...OK, so Dante777, "how complex?". This is a potentially critical piece of information. Do you know how to describe that complexity? Perhaps something as easy as:
SELECT
     t1.ID,
     SDO_UTIL.GETNUMVERTICES(t1.geom) as numVertices
FROM
     mytable t1;As an "up front piece of information" it would be very helpful.
Finally, there is an assumption because vital information was not provided up front:
I assume that your geometries are geodetic.To whit you reply:
The data is projected, not geodetic.
I send you an email with the layer in SHP.But could you have provided TWO sdo_geometry objects in the original post obviating the need for emailing shapefiles?
SELECT
     SDO_GEOM.SDO_DISTANCE(sdo_geometry(.....),sdo_geometry(.....), 0.05) as distance
FROM
     dual;So, in summary, this is about an appeal for posters asking for help to provide better information so that they will get an answer back much faster than otherwise and those willing to help will not waste hours and days reading between the lines.
Other forums for other Oracle and non-Oracle products ask for information up front - so should we.
In your case:
1. Whether or not the data is geodetic (SRID will do);
2. Two example geometries in an example SQL statement repliers can run to replicate the problem.
We can't replicate SQL execution on data - mytable - we don't have!
3. Information in indexing, number of rows and geometry complexity.
4. What version of the Oracle database you are running on (not mentioned in this article).
5. Perhaps what Operating System.
6. What client tool are you using? TOAD, SQuirreL, SQL Developer, SQLPlus?
Please everybody who creates a new posting: try and help us to help you.
Simon