[postgis-devel] automatic BVOL on spatial columns

[strk at refractions.net]

On Wed, Dec 29, 2004 at 10:25:40AM +0100, strk at refractions.net wrote:
> On Mon, Dec 27, 2004 at 07:50:39PM -0800, Paul Ramsey wrote:
> > I am loath to load more functionality in AddGeometryColumn, because I 
> > really really want to make it go away in the long term. I think it's a 
> > bit of nastiness.
> > 
> > How about a somewhat larger hammer? How about having bboxes for 
> > anything that is not a point and that has more than 4 vertices? or 8? 
> > something like that? Just a single rule, some compile-time defines for 
> > the bold, and leave it there?
> 
> The problem is that geometry construction happen in different ways,
> so the business logic in adding a BBOX cache should be applied
> in many different places (parser(s), serializer(s), functions
> autonomously constructing returns, GEOS converter).
> 
> Also, this logic should be left to the user, so she can decide when to
> cache and when not to. She might want fast load and successive
> bbox caching, she might want to cache bbox only on indexed tables,
> or only for geoms with npoints > X in a table and > Y in another.
> 
> I just don't see an easy way though :(

I've implemented a C trigger function (cache_bbox) intended
to be used for enforcing bbox caching for a specific field
in a table. Currently it requires an argument, being the
name of the geometry field:

  CREATE TRIGGER <name> BEFORE INSERT OR UPDATE
       ON <table> FOR EACH ROW EXECUTE PROCEDURE
       cache_bbox(<field>);

If you have more then a single field you need to add another
trigger for it. This allows for having (for example) a POINT
and a POLYGON geometry fields in the same table, one with
bbox cached and the other w/out.

A possible extension could be accepting multiple field name
arguments, or other types of conditions (like number of points
in the geometry).

Another one would be taking no args at all and cache bbox only
for those geometries having at least a compile-time defined number
of points (for *any* geometry field).

What do you think ?

> 
> --strk;
> 
> > 
> > P.
> > 
> > On 23-Dec-04, at 6:03 AM, strk at refractions.net wrote:
> > 
> > >The bounding box of an LWGEOM geometry is
> > >an optional 'cache', currently absent at
> > >construction time.
> > >
> > >Bounding boxes can be added using addBBOX(geom)
> > >and removed using dropBBOX(geom).
> > >
> > >Having a bbox cached speeds up bbox operation
> > >like &&, but increases on-disk size.
> > >
> > >Note that an index scan does not need to
> > >compute the bbox, but its construction does.
> > >Also note that our GiST index has a RECHECK
> > >clause on each operator, thus practically
> > >needing the bbox check (so it's computation)
> > >for every 'candidate' row returned from the
> > >index scan.
> > >
> > >Previous (HWGEOM) geometry type did *always*
> > >have this cache available.
> > >
> > >My proposal is to add a RULE on INSERT and
> > >UPDATES of geometry columns from within
> > >AddGeoemtryColumn, so that all geometry
> > >columns exept 'POINT' type (for which bbox
> > >computation is very fast) have a BBOX
> > >computed.
> > >
> > >What do you think ?
> > >
> > >--strk;
> > >_______________________________________________
> > >postgis-devel mailing list
> > >postgis-devel at postgis.refractions.net
> > >http://postgis.refractions.net/mailman/listinfo/postgis-devel
> > 
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> 
> -- 
> 
> 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/
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

-- 

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/