Sehr geehrter Absender, 

vielen Dank für Ihre Email.

Leider kann ich Ihre Nachricht im Moment nicht persönlich
beantworten, da ich mich bis zum 21.09.2007 im Urlaub befinden. 

Nach meiner Rückkehr am 24.09.2007 werde ich gerne Ihre Anfrage beantworten. 


Bitte wenden Sie sich in dringenden Fällen an Herrn Jens Schwarz, [EMAIL 
PROTECTED] oder per Telefon 08323-8006-0.

Mit freundlichen Grüßen

Hubert Burger
 

      
Alpstein GmbH                      
Missener Str. 18                   
87509 Immenstadt                   
                                 
fon  +49 8323 8006-0              
fax  +49 8323 8006-50             
 
web  www.alpstein.de

Mark,

> Yes. Number 1 is true because we have a RECHECK clause on the operator 
> class - it is this that provides the SRID checking since the SRID is 
> stored in the heap and not in the index.
> This might make sense since if you're storing country outlines then 
> the the geometries are likely to be quite large...

Right, RECHECK && seems to be enabled by default for gist indices. Why is that 
needed and how can I disable the RECHECK clause? In my case, SRID lookups are 
not necessary when a CHECK (srid(the_geom)=4326) constraint is used since all 
imported objects are guaranteed to have 4326 then, or am I wrong? I wonder what 
consequences would have changes or insertions of Geometry objects if I do 
disable the RECHECK clause? Aren't such changes stored into the gist index back 
again automatically?

I further still do not understand why the RECHECK times for the the_geom and 
bbox columns differ: It seems that the cached Geometry bounding box is *not* 
used and the whole Geometry object is scanned, *even if* hasbbox(the_geom) 
returns true for all objects. In my eyes this decreases strongly and 
unnecessarily the performance of certain bounding box queries.

Thank you!


=====

Kevin,

I followed your short instruction and got about the same measurement times. No 
other processes were running on the server at that time.

Any further ideas?

Thank you!

> -----Ursprüngliche Nachricht-----
> Von: PostGIS Users Discussion <[email protected]>
> Gesendet: 07.09.07 20:58:17
> An: PostGIS Users Discussion <[email protected]>
> Betreff: RE: [postgis-users] question on gist performance


> 
> On Fri, 2007-09-07 at 14:17 +0200, Stefan Zweig wrote:
> > Gregory (and others),
> > 
> > some questions occurred after reading your posts: 
> > 
> > 1. Is it true that each index match is revalidated by looking at the 
> > corresponding data row?
> > 2. Even it is true, both queries (based on the_geom or bbox, respecively) 
> > should then perform the *same* revalidation on the *same* (TOASTed) row 
> > data, resulting in identical query times?
> > 3. Could anybody clarify where and when index and row data is stored in the 
> > file system? How do I know what files contains what indices and row data?
> > 4. The bounding box cache should be inherent in the index, so 
> > hasBBOX(the_geom) should not play any role? (Btw, the result of 
> > hasBBOX(the_geom) is always true in our case, I even tried SELECT 
> > addbbox(the_geom) from mytable - without effect).
> > 
> > Thank you.
> 
> Yes. Number 1 is true because we have a RECHECK clause on the operator
> class - it is this that provides the SRID checking since the SRID is
> stored in the heap and not in the index. This might make sense since if
> you're storing country outlines then the the geometries are likely to be> 
> quite large...
> 
> 
> ATB,
> 
> Mark.
> 
> -- 
> ILande - Open Source Consultancy
> http://www.ilande.co.uk
> 
> 
> _______________________________________________
> postgis-users mailing list
> [email protected]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> 


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users


_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users

Reply via email to