[postgis-devel] automatic BVOL on spatial columns

strk at refractions.net strk at refractions.net
Tue Jan 11 06:27:58 PST 2005


Well, so we can't currently transport bbox caches decisions between
dump/reloads.

Is it still worth giving users the power of managing it ?
Or should we always decide transparently when to compute a bbox ?

I think this is the last issue before an RC1 release.

--strk;

On Tue, Jan 11, 2005 at 01:58:11PM +0100, Markus Schaber wrote:
> Hi, Strk,
> 
> On Tue, 11 Jan 2005 08:57:11 +0100
> strk at refractions.net wrote:
> 
> > Forgot to mention that I've implemented a trigger function for
> > the purpose of 'manually' mantaining the bbox cache.
> > The trigger use is based on the assumpion that you need a bbox cache
> > for specific tables and not in intermediate geometries (the ones
> > used for further manipulation).
> > 
> > To activate the trigger you sould issue the following command:
> > 
> > 	CREATE TRIGGER keep_cache
> > 		BEFORE INSERT OR UPDATE
> > 		ON mytable FOR EACH ROW
> > 		EXECUTE PROCEDURE cache_bbox('field');
> > 
> > When dumping/reloading the trigger will take the effect and still
> > ensure bbox cache for the relevant tables (the ones you'll use
> > for fast spatial queries).
> 
> As far as I tested it, pg_dump first issues the COPY command, and the
> CREATE TRIGGER afterwards. This makes sense because a dump usually is a
> snapshot that already contains the effects of all triggers and rules. So
> there is no need (and it can have bad side effects) to call the triggers
> again when reloading the dump.
> 
> So when you pg_dump your database, and then reload the dump, all bbox
> caches are lost because the canonical rep does not preserve them.
> 
> As this does not affect the default compiles that use the autocache, I
> do not see a big problem here, but it should be clearly documented so
> people who chose the manual approach know about the consequences.
> 
> > I haven't gone further with this, because Paul argued it would
> > be a too complex path for users, but it is still available as
> > it is if you set AUTOCACHE_BBOX to 0 in Makefile.config.
> > 
> > Maybe the whole bbox caching strategies should have their own
> > chapter in the manual ...
> 
> Yes, I think this should be clearly documented.
> 
> > > Nooo! Not another extension ;)
> 
> This was not my intention, sorry for frightening you :-)
> 
> Thanks for your good job,
> Markus
> 
> -- 
> markus schaber | dipl. informatiker
> logi-track ag | rennweg 14-16 | ch 8001 z├╝rich
> phone +41-43-888 62 52 | fax +41-43-888 62 53
> mailto:schabios at logi-track.com | www.logi-track.com
> _______________________________________________
> 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/



More information about the postgis-devel mailing list