[postgis-devel] PATCH: New positional operators based on Y position of bounding boxes

[Mark Cave-Ayland]

Hi strk,

> -----Original Message-----
> From: strk at refractions.net [mailto:strk at refractions.net] 
> Sent: 12 January 2005 09:38
> To: Mark Cave-Ayland
> Cc: 'PostGIS Development Discussion'
> Subject: Re: [postgis-devel] PATCH: New positional operators 
> based on Y position of bounding boxes

(cut)

> I've been asked to research on this for GUI applications, and 
> for that use the 'estimated' extent is ok (somehow better, if 
> you consider hard-deviants). It works even in absence of a 
> GiST index (stats are computed anyway), but only for PG8+.
> 
> Your version would be more widely usable (PG<80) and more 
> accurate, but would require a GiST index. I imagine it could 
> work transparently from inside extent() - using GiST if 
> available, and brute force otherwise.

I think I would envisage it as a separate function, something like
column_extent(), since people would still need to use extent() for
sub-selects, which will probably only make the code messier - it would also
mean we could point out obvious mistakes where people are trying to use
column_extent() in sub-selects and wondering why they are getting the wrong
result ;)
 
The other thing to consider would be to re-write the stats code so that PG80
and < PG80 share the same code. As far as I can see, the only difference
between the two versions should be where the data comes from - in the case
of PG80 it is the pg_statistic table, whereas for PG < 80 it is the
geometry_columns table. 

The ideal would be to take your (very good) statistical routines and
abstract them so that they use a separate function to fetch/store the data
for a column; the main routines would work using a pointer to an array of
palloc'd floats. It would then only be the fetch/store routines that would
be different, which would need to read/write the float arrays to either
pg_statistic or geometry_columns depending upon the correct version. It
should then be fairly trivial to get the estimated_extent() working for PG <
80, and would mean we could remove a lot of duplicate code from
lwgeom_estimate.c. This definitely something worth doing before we hit RC
stage IMHO.

> Probably we should not rush to have this included in RC1, but 
> I'll make some tests with it.

I agree. I don't think it's worth delaying going to RC because of it - we
can always work on it here on the development list and then commit it when
it's ready.


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