[postgis-users] Overlap Queries - speed
Bill Binko
bill at binko.net
Mon Oct 3 14:02:00 PDT 2005
On Mon, 3 Oct 2005, rb wrote:
> Thanks for the feedback, I have tried using the intersects() clause and
> it is still running (about 10 minutes going). You are right that there
> were many false posiives with the other. Here is the results of the
> explain :
>
>
> satest=# explain select a.msid, b.lrseg, b.landseg, b.riverseg,
> area2d(intersection(a.the_geom, b.the_geom))/area2d(b.the_geom) from
> bmp_multiseg as a, p5lrsegs as b where a.the_geom && b.the_geom;
> QUERY
> PLAN
> ----------------------------------------------------------------------------------------
> Nested Loop (cost=0.00..14498.24 rows=17870 width=28135)
> -> Seq Scan on p5lrsegs b (cost=0.00..98.64 rows=2364 width=11555)
> -> Index Scan using bmm_gix on bmp_multiseg a (cost=0.00..6.00
> rows=1 width=16580)
> Index Cond: (a.the_geom && "outer".the_geom)
> (4 rows)
>
>
> it seems to me that the index is being used. It has been analyzed and
> vacuumed about six brazillion times so far.
>
> So, I feel like a teenager: "Is this normal??"
>
You have Indexes on both Tables? I have seen places where it will not use
both. I have found that putting the index on the larger table is a big
improvement.
Is this normal..... Well, that's a tough one. Strk will have to actually
answer that. I will say that it's a known problem that "small numbers of
complex geometries" perform worse than "large numbers of simple
geometries". There are good reasons for this, but I don't know of a
solution.
Bill
More information about the postgis-users
mailing list