[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
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.
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 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
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