[Qgis-developer] Re: dealing with "long" primary keys

[wambacher]

Ivan Mincik-2 wrote:
> 
> Maybe somebody can briefly explain, what kind of technical problem there
> is. There is discussion about it every half a year and still I am not
> sure what is going on.
hi, let's go:

\d nodes
                 Tabelle »public.nodes«
    Spalte    |             Typ             | Attribute 
--------------+-----------------------------+-----------
 id           | bigint                      | not null
 version      | integer                     | not null
 user_id      | integer                     | not null
 tstamp       | timestamp without time zone | not null
 changeset_id | bigint                      | not null
 tags         | hstore                      | 
 geom         | geometry                    | 
Indexe:
    "pk_nodes" PRIMARY KEY, btree (id)
    "idx_nodes_geom" gist (geom) CLUSTER
Check-Constraints:
    "enforce_dims_geom" CHECK (st_ndims(geom) = 2)
    "enforce_geotype_geom" CHECK (geometrytype(geom) = 'POINT'::text OR geom
IS NULL)
    "enforce_srid_geom" CHECK (st_srid(geom) = 4326)

gis=# select max(id) from nodes;
    max     
------------
 1314039345


bigint = int*8/64bit,  id is primary key getting bigger and bigger every
minute.

Add new layer:

http://wnordmann.homeunix.com/images/stories/osm/forum/screenshot-postgis-tabellen%20hinzufgen.png

and then 

http://wnordmann.homeunix.com/images/stories/osm/forum/screenshot-kann%20die%20schlsselspalte%20nicht%20finden.png

can be tested in about 60 seconds. just create a table with pk type bigint
and try.

creating oid's wont't help as those are even bigger. OSM ist a really BIG
database!

that's all.

Regards

walter

btw: max(id) is now 1314048177  (20 minutes later)









--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/dealing-with-long-primary-keys-tp6440007p6444870.html
Sent from the qgis-developer mailing list archive at Nabble.com.