[postgis-devel] Prepared Geometry API

Obe, Regina robe.dnd at cityofboston.gov
Wed Oct 8 05:28:34 PDT 2008


Paul,
Would seem so.  Though I'd be more convinced if I saw a true
non-constant subquery.

Anyrate from your other threads, I take it you have put this out to
pasture and have decided on a memcpy based solution? 

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Tuesday, October 07, 2008 4:45 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Prepared Geometry API

I see the datum numbers are also consistently tracking changes when I
add those in:

POSTGIS_DEBUGF(1, "arg 1 pointer(%x) datum(%d)     arg 2 pointer(%x)
datum(%d)", PG_GETARG_POINTER(0), PG_GETARG_DATUM(0),
PG_GETARG_POINTER(1), PG_GETARG_DATUM(1));


Does this mean that using the datum numbers is a possible sol'n?

postgis2=#
                                         postgis2=# SELECT a.val as a,
b.val as b, _st_containsprepared(a.val, b.val,0)postgis2-#
FROMpostgis2-#  (SELECT 'POINT(0 0)'::geometry as val UNION SELECT
'POINT(1 1)'::geometry as val) a,
postgis2-#  (SELECT 'POINT(3 4)'::geometry as val UNION SELECT
'POINT(1 1)'::geometry as val) b;
NOTICE:  [lwgeom_geos_c.c:containsPrepared:3931] arg 1 pointer(731d7c)
datum(7544188)     arg 2 pointer(732e9c) datum(7548572)
NOTICE:  [lwgeom_geos_c.c:containsPrepared:3934] arg 1 ewkt: POINT(0 0)
NOTICE:  [lwgeom_geos_c.c:containsPrepared:3936] arg 2 ewkt: POINT(1 1)
NOTICE:  [lwgeom_geos_c.c:containsPrepared:3931] arg 1 pointer(731d7c)
datum(7544188)     arg 2 pointer(732e54) datum(7548500)
NOTICE:  [lwgeom_geos_c.c:containsPrepared:3934] arg 1 ewkt: POINT(0 0)
NOTICE:  [lwgeom_geos_c.c:containsPrepared:3936] arg 2 ewkt: POINT(3 4)
NOTICE:  [lwgeom_geos_c.c:containsPrepared:3931] arg 1 pointer(73302c)
datum(7548972)     arg 2 pointer(8586f4) datum(8750836)
NOTICE:  [lwgeom_geos_c.c:containsPrepared:3934] arg 1 ewkt: POINT(1 1)
NOTICE:  [lwgeom_geos_c.c:containsPrepared:3936] arg 2 ewkt: POINT(1 1)
NOTICE:  [lwgeom_geos_c.c:containsPrepared:3931] arg 1 pointer(73302c)
datum(7548972)     arg 2 pointer(732f4c) datum(7548748)
NOTICE:  [lwgeom_geos_c.c:containsPrepared:3934] arg 1 ewkt: POINT(1 1)
NOTICE:  [lwgeom_geos_c.c:containsPrepared:3936] arg 2 ewkt: POINT(3 4)
                     a                      |                     b
                  | _st_containsprepared
--------------------------------------------+---------------------------
-----------------+----------------------
 010100000000000000000000000000000000000000 |
0101000000000000000000F03F000000000000F03F | f
 010100000000000000000000000000000000000000 |
010100000000000000000008400000000000001040 | f
 0101000000000000000000F03F000000000000F03F |
0101000000000000000000F03F000000000000F03F | t
 0101000000000000000000F03F000000000000F03F |
010100000000000000000008400000000000001040 | f
(4 rows)



On Tue, Oct 7, 2008 at 1:29 PM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Obe, Regina wrote:
>>
>> 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
>
> The UNION ALL seems to work for me. Using the attached patch against
SVN
> trunk and EXPLAIN, it is possible to see that it is the Materialize
node
> which causes the Datum pointers to change. Also it's worth noting that
> st_contains() invokes the bounding box filter first which is a little
> confusing when looking at this - things were a lot clearer to me using
the
> following queries:
>
>
> SELECT a.val as a, b.val as b, _st_containsprepared(a.val, b.val,0)
> FROM
>  (SELECT 'POINT(0 0)'::geometry as val UNION SELECT 'POINT(1
1)'::geometry
> as val) a,
>  (SELECT 'POINT(3 4)'::geometry as val UNION SELECT 'POINT(1
1)'::geometry
> as val) b;
>
>
> SELECT a.val as a, b.val as b, _st_containsprepared(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;
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
>
> _______________________________________________
> 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
-----------------------------------------
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.



More information about the postgis-devel mailing list