[postgis-devel] Prepared Geometry API

Paul Ramsey pramsey at cleverelephant.ca
Wed Oct 8 08:45:59 PDT 2008


Mark figures Materialize will re-number everything, so there's no
guarantees. Given the memcmp speed results, and the desire on this
list to retain a uniform API, I'm going go finish moving everything to
memcmp so we can close this chapter.

P.

On Wed, Oct 8, 2008 at 5:28 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> 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.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>



More information about the postgis-devel mailing list