<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [postgis-devel] Prepared Geometry API</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Paul,<BR>
<BR>
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.<BR>
<BR>
What does the revised query give you<BR>
<BR>
SELECT a.val as a, b.val as b, st_contains(a.val, b.val,0)<BR>
FROM<BR>
(SELECT 'POINT(0 0)'::geometry as val UNION ALL SELECT 'POINT(1 1)'::geometry as val) a,<BR>
(SELECT 'POINT(3 4)'::geometry as val UNION ALL SELECT 'POINT(1 1)'::geometry as val) b;<BR>
<BR>
Thanks,<BR>
Regina<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Obe, Regina<BR>
Sent: Mon 10/6/2008 4:15 PM<BR>
To: PostGIS Development Discussion<BR>
Subject: RE: [postgis-devel] Prepared Geometry API<BR>
<BR>
<BR>
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.<BR>
<BR>
R<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Paul Ramsey<BR>
Sent: Mon 10/6/2008 2:59 PM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] Prepared Geometry API<BR>
<BR>
Exactly as one would expect: sometimes :)<BR>
<BR>
P<BR>
<BR>
On Mon, Oct 6, 2008 at 11:52 AM, Obe, Regina <robe.dnd@cityofboston.gov> wrote:<BR>
> What about using the PG_GETARG_POINTER does that return the same for all<BR>
> constants too?<BR>
><BR>
> -----Original Message-----<BR>
> From: postgis-devel-bounces@postgis.refractions.net<BR>
> [<A HREF="mailto:postgis-devel-bounces@postgis.refractions.net">mailto:postgis-devel-bounces@postgis.refractions.net</A>] On Behalf Of Paul<BR>
> Ramsey<BR>
> Sent: Monday, October 06, 2008 2:48 PM<BR>
> To: PostGIS Development Discussion<BR>
> Subject: Re: [postgis-devel] Prepared Geometry API<BR>
><BR>
> The answer seems to be that, for data in tables, this works OK, but<BR>
> for literals, it's possible for different literals to get the same<BR>
> datum number:<BR>
><BR>
> select a.val as a, b.val as b, st_contains(a.val, b.val, 0) from<BR>
> (select 'POINT(0 0)' as val union select 'POINT(1 1)' as val) a,<BR>
> (select 'POINT(0 0)' as val union select 'POINT(1 1)' as val) b;<BR>
><BR>
> This ends up returning the same datum number for 0,0 as well as 1,1. :(<BR>
><BR>
> P.<BR>
><BR>
> On Mon, Oct 6, 2008 at 11:23 AM, Paul Ramsey <pramsey@cleverelephant.ca><BR>
> wrote:<BR>
>> Why can't I just this this:<BR>
>><BR>
>> key1 = PG_GETARG_DATUM(0)<BR>
>> key2 = PG_GETARG_DATUM(1)<BR>
>><BR>
>> the datums are just uint, and they don't get turned into pointers<BR>
>> until further down the line... I just tried changing my contains code<BR>
>> to do this, and I got the same answer in the same amount of time. Are<BR>
>> the datum numbers reliable "object identifiers"?<BR>
>><BR>
>> P.<BR>
>><BR>
>> On Mon, Oct 6, 2008 at 10:53 AM, David Fuhry <dfuhry@acm.org> wrote:<BR>
>>> ctid will work for that, but I believe it would have to be passed<BR>
> into the<BR>
>>> function as a separate argument from the geometry, so API ugliness<BR>
> remains.<BR>
>><BR>
> _______________________________________________<BR>
> postgis-devel mailing list<BR>
> postgis-devel@postgis.refractions.net<BR>
> <A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
> -----------------------------------------<BR>
> The substance of this message, including any attachments, may be<BR>
> confidential, legally privileged and/or exempt from disclosure<BR>
> pursuant to Massachusetts law. It is intended<BR>
> solely for the addressee. If you received this in error, please<BR>
> contact the sender and delete the material from any computer.<BR>
> _______________________________________________<BR>
> postgis-devel mailing list<BR>
> postgis-devel@postgis.refractions.net<BR>
> <A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
><BR>
_______________________________________________<BR>
postgis-devel mailing list<BR>
postgis-devel@postgis.refractions.net<BR>
<A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
<HTML><BODY><P><hr size=1></P>
<P><STRONG>
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.
</STRONG></P></BODY></HTML>
<P><hr size=1></P>
<P><STRONG><font size="2" color="339900"> Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper. </p> <p> </font></STRONG></P>