This isn't a "bug" per se, because it's doing exactly what we "want",
but I think it's very possible we don't "want" to do this.
We have so many other checks and balances with regard to SRID coherence
(in index building, in the table constraints build by the default
loader, in the geometry com
On Thu, 2007-09-13 at 15:26 +0200, Stefan Zweig wrote:
> Mark,
>
> thank you very much for your response. As far as I understand, pre-computed
> bounding boxes are stored (by default) to each Geometry object (wherever that
> is) to "make bounding box based queries faster", see
>
> http://main.m
On Mon, 2007-09-10 at 11:40 +0200, Stefan Zweig wrote:
> 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 a
--Ursprüngliche Nachricht-
> Von: PostGIS Users Discussion
> Gesendet: 07.09.07 20:58:17
> An: PostGIS Users Discussion
> Betreff: RE: [postgis-users] question on gist performance
>
> On Fri, 2007-09-07 at 14:17 +0200, Stefan Zweig wrote:
> > Gregory (and others),
> >
Gesendet: 07.09.07 20:58:17
> An: PostGIS Users Discussion
> 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:
>
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,
Stefan Zweig wrote:
EXPLAIN ANALYZE SELECT gid FROM mytable WHERE the_geom &&
SetSrid('BOX(13.760675 51.171104,15.231802 51.83737)'::box2d,4326);
"Index Scan using mytable_the_geom_gist on mytable (cost=0.00..4.95 rows=1 width=4)
(actual time=100.198..247.711 rows=4 loops=1)"
" Index Co
uot;PostGIS Users Discussion"
> Betreff: RE: [postgis-users] question on gist performance
>
> I may be wrong, but I think that once PostgreSQL gets a match from the index,
> it has to go to disk to "make sure" that the data is valid (i.e. visible
> given the rules of the
.2.1" GEOS="2.2.3-CAPI-1.1.1" PROJ="Rel. 4.4.9, 29 Oct 2004"
USE_STATS"
> SELECT version();
"PostgreSQL 8.1.8 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.5 (Debian
1:3.3.5-13)"
As you see, the_geom is *not* selected (which may also increase query tim
tand it -- retreaded Informix guy
myself). Perhaps that accounts for some of the timing difference ?
GSW
-Original Message-
From: [EMAIL PROTECTED] on behalf of Stefan Zweig
Sent: Fri 9/7/2007 5:21 AM
To: PostGIS Users Discussion
Subject: RE: [postgis-users] question on gist performance
is, as you surmised, that
extra time is needed to create the bbox from the geometry.
GSW
-Original Message-
From: Gregory Williamson
Sent: Fri 9/7/2007 4:18 AM
To: PostGIS Users Discussion; PostGIS Users Discussion
Subject: RE: [postgis-users] question on gist performance
To my untutored ey
Ursprüngliche Nachricht-
> Von: PostGIS Users Discussion
> Gesendet: 07.09.07 12:21:26
> An: "PostGIS Users Discussion"
> Betreff: RE: [postgis-users] question on gist performance
>
> To my untutored eye it looks like the slower one is using the geometry
> (&quo
sters made me say this.)
-Original Message-
From: [EMAIL PROTECTED] on behalf of Stefan Zweig
Sent: Fri 9/7/2007 3:36 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] question on gist performance
hi frank,
this what analyze says:
"Index Scan using mytable_the_geom_gist
Setfan,
* Stefan Zweig <[EMAIL PROTECTED]> [070907 11:36]:
> this what analyze says:
the following output looks like from EXPLAIN, not from EXPLAIN ANALYSE,
the actual timings, loops etc are missing. Could you please repost?
> "Index Scan using mytable_the_geom_gist on mytable (cost=0.00..4.95
3-CAPI-1.1.1" PROJ="Rel. 4.4.9, 29 Oct 2004"
USE_STATS"
> SELECT version();
"PostgreSQL 8.1.8 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.5 (Debian
1:3.3.5-13)"
As you see, the_geom is *not* selected (which may also increase query time).
Are possibly
nformation from them (which i actually would not have thought so)?
kind regards, stefan
> -Ursprüngliche Nachricht-
> Von: PostGIS Users Discussion
> Gesendet: 07.09.07 10:44:16
> An: PostGIS Users Discussion
> Betreff: Re: [postgis-users] question on gist performance
&
Stefan,
* Stefan Zweig <[EMAIL PROTECTED]> [070907 10:07]:
> thanks for your quick reply. i have tried your advice and rebuilded
> all my gist indexes on the table (via drop index, create index) and
> run a vacuum full afterwards. but that did not change the fact, that
> the query on the_geom is m
to be the same problem.
any ideas?
thanks in advance, stefan
> -Ursprüngliche Nachricht-
> Von: PostGIS Users Discussion
> Gesendet: 06.09.07 09:40:18
> An: PostGIS Users Discussion
> Betreff: Re: [postgis-users] question on gist performance
>
> On Wed, 2007-09-
On Wed, 2007-09-05 at 18:12 +0200, Stefan Zweig wrote:
> hi list,
>
> i have noticed a strange thing while selecting geometries from a table and
> using the && operator (gist):
>
> i have a table which holds all countrys of the world (somewhat more than 200)
> an their boundaries in column the_
19 matches
Mail list logo
