[postgis-devel] GiST estimate and index_extent()

Mark Cave-Ayland m.cave-ayland at webbased.co.uk
Wed Jan 12 05:59:23 PST 2005


Hi strk,

> -----Original Message-----
> From: strk at refractions.net [mailto:strk at refractions.net] 
> Sent: 12 January 2005 12:59
> To: Mark Cave-Ayland
> Cc: 'PostGIS Development Discussion'
> Subject: Re: [postgis-devel] GiST estimate and index_extent()

(cut)

> I agree, but it needs a name avoiding clashes with other 
> packages. Could it be a generic GiST function ? 

Well I suppose it would be particular to R-Trees as opposed to GiST?

(cut)
 
> mmm.. geometry_columns.stats is of type histogram2 
> (LWHISTOGRAM2d struct). array of float is used as the 
> GEOM_STATS structure. Cleanest way would be make 
> geometry_columns.stats a float[], 
> but this would require a post-upgrade routine to fix the
> table definition.

Agreed, an array of floats would be the best way to do this. Looking at the
definition files, I think we would need to also include a stakind column in
geometry_columns for PG < 80 too. I'm thinking that if we need to change the
algorithm/layout of the geometry columns then the first thing we would do
would be to create a new statistical type other than
STATISTICS_KIND_GEOMETRY, and having the stakind field in geometry_columns
would enable us to detect the version of statistics in use.

It may be possible to use the presence of this column to determine whether
or not we need to run a post-upgrade fix routine from
update_geometry_stats() on PG < 80 as it wouldn't be present in dumps from
older versions of PostGIS.

> Incompatibilities between the two types are:
> 
> 	o LWHISTOGRAM2D has boxesPerSide while GEOM_STATS
> 	  has separated cols and rows.
> 
> 	o GEOM_STATS has avgFeatureCells, missing in LWHISTOGRAM2D
> 
> 	o avgFeatureArea and extent coords are double for LWHISTOGRAM2D
> 	  and floats for GEOM_STATS.
> 	  has separated cols and rows.

I'm convinced even more that unifying the two is the way to go - for example
if we find a fundamental problem with the statistics after release then we
have to fix and test in two separate places, which will also make it harder
to locate any bugs in the code. The main reason is, of course, that we know
your statistics routines give better results than Dave's! ;)


Kind regards,

Mark.

------------------------
WebBased Ltd
South West Technology Centre
Tamar Science Park
Plymouth
PL6 8BT 

T: +44 (0)1752 791021
F: +44 (0)1752 791023
W: http://www.webbased.co.uk





More information about the postgis-devel mailing list