[postgis-users] ordering spatial data in tables - WARNING! BUG?

Ben Madin ben at remoteinformation.com.au
Wed Jan 7 13:32:48 PST 2009


G'day Vincent,

This didn't work as anticipated - in fact it appears to have truncated  
the table!

On 08/01/2009, at 5:01 AM, postgis-users- 
request at postgis.refractions.net wrote:

> Another and more <classic> solution (despite slower on big tables) to
> keep spatially close rows together on disk is to use postgresql  
> CLUSTER
> statement.
> http://www.postgresql.org/docs/8.3/static/sql-cluster.html
>
> CLUSTER reorders data on disk using a specified index, therefore
> increasing access speed when reading rows in the index order.
>
> Example :
> CREATE INDEX idx_mytable_the_geom ON mytable USING GIST(the_geom);
> CLUSTER mytable USING idx_mytable_the_geom;


CLUSTER works on a normal index :

# select count(*) from gis_roads;
  count
-------
  89618
(1 row)

# CLUSTER gis_roads USING gis_roads_gid_key;

CLUSTER
# select count(*) from gis_roads;
  count
-------
  89618
(1 row)

all good!

But when I try on the gist index


# CLUSTER gis_roads USING gis_roads_gist;
CLUSTER

# select count(*) from gis_roads;
  count
-------
      0
(1 row)

whoops!

Is this something I missed? Is this a PostgreSQL bug... surely the  
cluster command shouldn't be allowed to destroy a whole table.

cheers

Ben





-- 

Ben Madin
REMOTE INFORMATION

t : +61 8 9192 5455
f : +61 8 9192 5535
m : 0448 887 220
Broome   WA   6725

ben at remoteinformation.com.au



							Out here, it pays to know...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20090108/f29872ed/attachment.html>


More information about the postgis-users mailing list