we get always error when selecting pgr_dijkstra

[walpino]

Expected behavior and actual behavior we imported in the meantime some osm mapfiles with osm2pgrouting and now we want to calc the shortest path but we get always errors we have now some tables in our postges database called

ways

we followed the explanation there http://docs.pgrouting.org/pdf/en/pgRoutingDocumentation-2.5.1.pdf so I guess we dont have to create an topology and "myroads" is equal to ways in our case??

Steps to reproduce the problem

SELECT seq, id1 AS node, id2 AS edge, cost FROM pgr_dijkstra(' SELECT gid AS id, source::integer, target::integer, length::double precision AS cost FROM ways', 30, 60, false, false); NOTICE: Deprecated function ERROR: Error, columns 'source', 'target' must be of type int4, 'cost' must be of type float8 CONTEXT: PL/pgSQL function _pgr_parameter_check(text,text,boolean) line 40 at RAISE PL/pgSQL function pgr_dijkstra(text,integer,integer,boolean,boolean) line 7 at assignment homegate_test=>

Specifications like the version of pgRouting/PostGIS and PostgreSQL as well as Operating System cnetos SELECT version(); version PostgreSQL 9.6.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16), 64-bit (1 row)

SELECT postgis_full_version(); postgis_full_version POSTGIS="2.4.3 r16312" PGSQL="96" GEOS="3.6.2-CAPI-1.10.2 4d2925d6" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL 1.11.4, released 2016/01/25" LIBXML="2.9.1" LIBJSON="0.11" RASTER (1 row)

SELECT pgr_version(); pgr_version (2.5.2,v2.5.2,60585f1f7,master,1.53.0) (1 row)

Use the commands:

SELECT version(); SELECT postgis_full_version(); SELECT pgr_version(); any idea where it is stucked? or what takes so long? the machine has 10 cpus and 50 gb of ram

[rohithsankepally]

@walpino The query you are trying to execute is

SELECT seq, id1 AS node, id2 AS edge, cost FROM pgr_dijkstra('
SELECT gid AS id,
source::integer,
target::integer,
length::double precision AS cost
FROM ways',
30, 60, false, false);

Let us try to map your query to the signature of one to one version of pgr_dijkstra given below.

pgr_dijkstra(TEXT edges_sql, BIGINT start_vid, BIGINT end_vid,
    BOOLEAN directed:=true);
RETURNS SET OF (seq, path_seq, node, edge, cost, agg_cost) or EMPTY SET

edges_sql - 'SELECT gid AS id, source::integer, target::integer, length::double precision AS cost FROM ways' start_vid - 30 end_vid - 60 directed - false I notice another false value given as the input to the query which is inconsistent with the latest signature and thus gives you an error

Your query can be modified as follows

SELECT seq, id1 AS node, id2 AS edge, cost FROM pgr_dijkstra('
SELECT gid AS id,
source::integer,
target::integer,
length::double precision AS cost
FROM ways',
30, 60, false);

[walpino]

okay so there is just one boolean okay I see at some "documentation" there were 2 boolean parameters

so know it runs but it is so slow - I mean slower than slow

[cvvergara]

You are using a deprecated signature and to keep backwards compatibility there are a lot of coding to:

• to verify that your data is integer, and that it will raise an exception if you try to use a BIGINT
• that you are not giving a contradiction like having the has_rcost set to false, but the query has it. and if you have the contradiction, the graph is modified to not have the reverse_cost
• calls the new function
• converts the nice output seq, path_seq, node, edge, cost, agg_cost to be seq, id1, id2

Conclusion: lots of overhead when you want to keep on using the deprecated signatures. This comment of yours

at some "documentation" there were 2 boolean parameters

make me think that you want to use a signature you read about around 2013 of version 2.0, even that you are using 2.5.2

I strongly suggest that you read the documentation of the version you are using.

SELECT * FROM pgr_dijkstra('
SELECT gid AS id,
source,
target,
length AS cost
FROM ways',
30, 60, directed:=false);