[postgis-devel] Boxes cache and type (was: Caching Double-basedBoxes)

[Paragon Corporation]

Sorry for top posting.
There are a couple of reasons I want to punt this decision til 2.1

1) 9.2 has index only scan which will be useful for computing things like
ST_Extent and so forth, then it will be valuable for 
us to have indexes that are double-precision, but Paul isn't even proposing
that so why am I even bothering with this.

http://rhaas.blogspot.com/2011/10/index-only-scans-weve-got-em.html

2) The only real reason to do this in my mind is what Paul said:
"Not really. The && operators all go through functions which force the
boxes into float space first, so both sequence scans and index
assisted runs of the operators return the same results. Important
stuff. I think there will be fewer instances of inconsistency with
this approach."

and Sandro's concern about having consistent answers regardless of function.
I question if doing double-precision is the only way
to achieve those goals.

These are all edge cases.  Yah I have come across them, but they haven't
been that big of a deal.

3) If we do this we really got to thouroughly test out the consequences of
this.  I for one do not have time 
for this given all the other stuff I want/NEED to get done.

If any of you feel really strongly about having this in 2.0, then do the
work and test Paul's branch and with huge data sets not tincy one.
I ain't doing it.  I'm going to have enough discrepancies between 1.5 and
2.0 to benchmark that this will only add
noise to my tests.  Noise I don't care for.

4) strk -- there is a big difference between being prepared for and having
to.
I'm prepared to dump/reload, but it would be REALLY REALLY nice if I don't
have to.

Because I definitely will HAVE TO in 2.1 regardless of whether or not this
half-double precision thing happens in 2.0 or not 
and I'm well prepared for that eventuality.

Thanks,
Regina

> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net 
> [mailto:postgis-devel-bounces at postgis.refractions.net] On 
> Behalf Of Sandro Santilli
> Sent: Friday, November 25, 2011 4:16 AM
> To: PostGIS Development Discussion
> Subject: [postgis-devel] Boxes cache and type (was: Caching 
> Double-basedBoxes)
> 
> On Fri, Nov 25, 2011 at 09:09:09AM +0100, Nicklas Avén wrote:
> > > When I left, I remember we had a RECHECK issued in place.
> > > Is the RECHECK still there ? If it is, the presence of index 
> > > shouldn't change the view on reality.
> > 
> > There is no RECHECK when we are talking about knn and ordering. 
> 
> Ok.
> 
> > SELECT id, ST_Distance(a, b), a<->b FROM
> 
> I now realize this is a non-issue really.
> ST_Distance is checking realdistance, while <-> is checking 
> distance between the center of the bounding box.
> 
> The fact that the center of a bounding box of a point may not 
> be exactly the point is not a problem, to me.
> If a microunit error is critical for your application you're 
> likely choosing your units in a wrong way and shouldn't rely 
> on bounding-box based computations anyway.
> 
> Since we're at it, I would add that I don't even care if we 
> always use float-based bounding boxes, as long as we are 
> consistent about it (and wouldn't require a dump/reload).
> 
> I think it'd be important to brainstorm about this now as 
> next step is I'd like to see a BBOX first class types coming 
> out which would then be used to represent bounding boxes of 
> all our spatial types (geometry, geography, topogeometry,
> raster) and could then be used as key into the index as as 
> the only valid operand for bounding-box oriented operators 
> (&&, <->, <#>, $>, $<, $@, ...) and functions (st_extent?).
> 
> Such new type might greatly simplify the code in that every 
> spatial type would only need to provide an implicit cast to 
> the new type in order to get all the operators and indexing 
> support w/out code duplication.
> 
> --strk; 
> 
>   ()   Free GIS & Flash consultant/developer
>   /\   http://strk.keybit.net/services.html
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>