From: | "Kenneth Chan" <kkchan(at)technologist(dot)com> |
---|---|
To: | <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Polygons passed to poly_overlap have 0 pts when |
Date: | 2002-05-30 01:40:15 |
Message-ID: | 20020530014015.66592.qmail@iname.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hmmm, the really simple example didn't work probably becaure there are not enough rows in the test tables for the system to use the index instead of doing a sequential scan.
For poly_contained and other functions that use npts, maybe the code can take into account that npts maybe 0 by doing the bounding box test and proceed to more accurate tests only if npts > 0.
Ken.
----- Original Message -----
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Tue, 28 May 2002 23:29:08 -0400
To: "Kenneth Chan" <kkchan(at)technologist(dot)com>
Subject: Re: [HACKERS] Polygons passed to poly_overlap have 0 pts when column is indexed using rtree
> ... Turned out that npts of the
> polygon retrieved from the table is 0 (the other polygon is a constant
> and its attributes are correct). I suspect the feature might
> affect other functions that uses polygons->npts like poly_contain.
> Would anyone happens to know the identity of the offending
> function might be? TIA
It appears that the issue is not rtree itself, but the rt_poly_union
and rt_poly_inter functions, which produce "polygons" that have only
bounding boxes. Not sure whether that should be considered erroneous
or not. The dummy polygons are evidently used as internal node keys
in the rtree.
--
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2002-05-30 03:05:18 | self-tuning histograms |
Previous Message | Ola Sundell | 2002-05-30 00:45:20 | ipv6 |