[postgis-devel] GiST estimate and index_extent()

[strk at refractions.net]

Mark, I think RC1 must really come out now...
And the histogram2d handling seems not straihtforward to me.

I think what we need is a "live" upgrade script, able to update
a live installation from RC1 up. This would simplify operations
like changing geometry_columns definition and the like.

--strk;

On Wed, Jan 12, 2005 at 01:59:23PM -0000, Mark Cave-Ayland wrote:
> 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
> 

-- 

For standing up against patentability of software,

  Thank You, Poland!

Read the intervention:    http://kwiki.ffii.org/ConsPolon041221En
Send your thanks:         thankyoupoland.info
Read/do more:		  http://www.noepatents.org/