[postgis-devel] Prepared Geometry API

[Obe, Regina]

Paul,

Something is bugging me about your choice of example.  Not that it is important, but your a and b tables are the same constant so I would expect a planner to realize that and make a and b point to the same thing.  I'm not sure how that muddies your analysis. Also your constant gets cast as a geometry only when it gets into ST_Contains and you are doing a UNION instead of a UNION ALL.

What does the revised query give you

SELECT a.val as a, b.val as b, st_contains(a.val, b.val,0) 
FROM
 (SELECT 'POINT(0 0)'::geometry as val UNION ALL SELECT 'POINT(1 1)'::geometry as val) a,
 (SELECT 'POINT(3 4)'::geometry as val UNION ALL SELECT 'POINT(1 1)'::geometry as val) b;

Thanks,
Regina



-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Obe, Regina
Sent: Mon 10/6/2008 4:15 PM
To: PostGIS Development Discussion
Subject: RE: [postgis-devel] Prepared Geometry API
 

I guess there is no way to know when we are dealing with a constant e.g. by the look of the pointer or DATUM?  Then at least we know the information is no good and we resort to the old way.  I think if we can do that, it will probably take care of most use-cases anyway and the others will just be as they were.

R

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Mon 10/6/2008 2:59 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Prepared Geometry API
 
Exactly as one would expect: sometimes :)

P

On Mon, Oct 6, 2008 at 11:52 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> What about using the PG_GETARG_POINTER does that return the same for all
> constants too?
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
> Ramsey
> Sent: Monday, October 06, 2008 2:48 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Prepared Geometry API
>
> The answer seems to be that, for data in tables, this works OK, but
> for literals, it's possible for different literals to get the same
> datum number:
>
> select a.val as a, b.val as b, st_contains(a.val, b.val, 0) from
> (select 'POINT(0 0)' as val union select 'POINT(1 1)' as val) a,
> (select 'POINT(0 0)' as val union select 'POINT(1 1)' as val) b;
>
> This ends up returning the same datum number for 0,0 as well as 1,1. :(
>
> P.
>
> On Mon, Oct 6, 2008 at 11:23 AM, Paul Ramsey <pramsey at cleverelephant.ca>
> wrote:
>> Why can't I just this this:
>>
>> key1 = PG_GETARG_DATUM(0)
>> key2 = PG_GETARG_DATUM(1)
>>
>> the datums are just uint, and they don't get turned into pointers
>> until further down the line... I just tried changing my contains code
>> to do this, and I got the same answer in the same amount of time.  Are
>> the datum numbers reliable "object identifiers"?
>>
>> P.
>>
>> On Mon, Oct 6, 2008 at 10:53 AM, David Fuhry <dfuhry at acm.org> wrote:
>>> ctid will work for that, but I believe it would have to be passed
> into the
>>> function as a separate argument from the geometry, so API ugliness
> remains.
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20081006/50716c21/attachment.html>