<!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>Hmm okay. Don't see why renumbering is a bad thing unless it uses a number right from the previous materialize that you still have in your cache. I'm still trying to visualize a query that would have multiple materializations where the materialized numbers would actually be reused within the query. I would expect other use cases aside from PostGIS use to crumble.<BR>
<BR>
I guess better to close the chapter safely than risk something. Though would be interesting to reopen this chapter later. <BR>
<BR>
So are you guessing you will suffer 5-10% speed loss with using memcmp over using datum assuming datum is safe?<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Paul Ramsey<BR>
Sent: Wed 10/8/2008 11:45 AM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] Prepared Geometry API<BR>
<BR>
Mark figures Materialize will re-number everything, so there's no<BR>
guarantees. Given the memcmp speed results, and the desire on this<BR>
list to retain a uniform API, I'm going go finish moving everything to<BR>
memcmp so we can close this chapter.<BR>
<BR>
P.<BR>
<BR>
On Wed, Oct 8, 2008 at 5:28 AM, Obe, Regina <robe.dnd@cityofboston.gov> wrote:<BR>
> Paul,<BR>
> Would seem so. Though I'd be more convinced if I saw a true<BR>
> non-constant subquery.<BR>
><BR>
> Anyrate from your other threads, I take it you have put this out to<BR>
> pasture and have decided on a memcpy based solution?<BR>
><BR>
> Thanks,<BR>
> Regina<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: Tuesday, October 07, 2008 4:45 PM<BR>
> To: PostGIS Development Discussion<BR>
> Subject: Re: [postgis-devel] Prepared Geometry API<BR>
><BR>
> I see the datum numbers are also consistently tracking changes when I<BR>
> add those in:<BR>
><BR>
> POSTGIS_DEBUGF(1, "arg 1 pointer(%x) datum(%d) arg 2 pointer(%x)<BR>
> datum(%d)", PG_GETARG_POINTER(0), PG_GETARG_DATUM(0),<BR>
> PG_GETARG_POINTER(1), PG_GETARG_DATUM(1));<BR>
><BR>
><BR>
> Does this mean that using the datum numbers is a possible sol'n?<BR>
><BR>
> postgis2=#<BR>
> postgis2=# SELECT a.val as a,<BR>
> b.val as b, _st_containsprepared(a.val, b.val,0)postgis2-#<BR>
> FROMpostgis2-# (SELECT 'POINT(0 0)'::geometry as val UNION SELECT<BR>
> 'POINT(1 1)'::geometry as val) a,<BR>
> postgis2-# (SELECT 'POINT(3 4)'::geometry as val UNION SELECT<BR>
> 'POINT(1 1)'::geometry as val) b;<BR>
> NOTICE: [lwgeom_geos_c.c:containsPrepared:3931] arg 1 pointer(731d7c)<BR>
> datum(7544188) arg 2 pointer(732e9c) datum(7548572)<BR>
> NOTICE: [lwgeom_geos_c.c:containsPrepared:3934] arg 1 ewkt: POINT(0 0)<BR>
> NOTICE: [lwgeom_geos_c.c:containsPrepared:3936] arg 2 ewkt: POINT(1 1)<BR>
> NOTICE: [lwgeom_geos_c.c:containsPrepared:3931] arg 1 pointer(731d7c)<BR>
> datum(7544188) arg 2 pointer(732e54) datum(7548500)<BR>
> NOTICE: [lwgeom_geos_c.c:containsPrepared:3934] arg 1 ewkt: POINT(0 0)<BR>
> NOTICE: [lwgeom_geos_c.c:containsPrepared:3936] arg 2 ewkt: POINT(3 4)<BR>
> NOTICE: [lwgeom_geos_c.c:containsPrepared:3931] arg 1 pointer(73302c)<BR>
> datum(7548972) arg 2 pointer(8586f4) datum(8750836)<BR>
> NOTICE: [lwgeom_geos_c.c:containsPrepared:3934] arg 1 ewkt: POINT(1 1)<BR>
> NOTICE: [lwgeom_geos_c.c:containsPrepared:3936] arg 2 ewkt: POINT(1 1)<BR>
> NOTICE: [lwgeom_geos_c.c:containsPrepared:3931] arg 1 pointer(73302c)<BR>
> datum(7548972) arg 2 pointer(732f4c) datum(7548748)<BR>
> NOTICE: [lwgeom_geos_c.c:containsPrepared:3934] arg 1 ewkt: POINT(1 1)<BR>
> NOTICE: [lwgeom_geos_c.c:containsPrepared:3936] arg 2 ewkt: POINT(3 4)<BR>
> a | b<BR>
> | _st_containsprepared<BR>
> --------------------------------------------+---------------------------<BR>
> -----------------+----------------------<BR>
> 010100000000000000000000000000000000000000 |<BR>
> 0101000000000000000000F03F000000000000F03F | f<BR>
> 010100000000000000000000000000000000000000 |<BR>
> 010100000000000000000008400000000000001040 | f<BR>
> 0101000000000000000000F03F000000000000F03F |<BR>
> 0101000000000000000000F03F000000000000F03F | t<BR>
> 0101000000000000000000F03F000000000000F03F |<BR>
> 010100000000000000000008400000000000001040 | f<BR>
> (4 rows)<BR>
><BR>
><BR>
><BR>
> On Tue, Oct 7, 2008 at 1:29 PM, Mark Cave-Ayland<BR>
> <mark.cave-ayland@siriusit.co.uk> wrote:<BR>
>> Obe, Regina wrote:<BR>
>>><BR>
>>> Paul,<BR>
>>><BR>
>>> Something is bugging me about your choice of example. Not that it is<BR>
>>> important, but your a and b tables are the same constant so I would<BR>
> expect a<BR>
>>> planner to realize that and make a and b point to the same thing.<BR>
> I'm not<BR>
>>> sure how that muddies your analysis. Also your constant gets cast as<BR>
> a<BR>
>>> geometry only when it gets into ST_Contains and you are doing a UNION<BR>
>>> 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<BR>
>>> 1)'::geometry as val) a,<BR>
>>> (SELECT 'POINT(3 4)'::geometry as val UNION ALL SELECT 'POINT(1<BR>
>>> 1)'::geometry as val) b;<BR>
>>><BR>
>>> Thanks,<BR>
>>> Regina<BR>
>><BR>
>> The UNION ALL seems to work for me. Using the attached patch against<BR>
> SVN<BR>
>> trunk and EXPLAIN, it is possible to see that it is the Materialize<BR>
> node<BR>
>> which causes the Datum pointers to change. Also it's worth noting that<BR>
>> st_contains() invokes the bounding box filter first which is a little<BR>
>> confusing when looking at this - things were a lot clearer to me using<BR>
> the<BR>
>> following queries:<BR>
>><BR>
>><BR>
>> SELECT a.val as a, b.val as b, _st_containsprepared(a.val, b.val,0)<BR>
>> FROM<BR>
>> (SELECT 'POINT(0 0)'::geometry as val UNION SELECT 'POINT(1<BR>
> 1)'::geometry<BR>
>> as val) a,<BR>
>> (SELECT 'POINT(3 4)'::geometry as val UNION SELECT 'POINT(1<BR>
> 1)'::geometry<BR>
>> as val) b;<BR>
>><BR>
>><BR>
>> SELECT a.val as a, b.val as b, _st_containsprepared(a.val, b.val,0)<BR>
>> FROM<BR>
>> (SELECT 'POINT(0 0)'::geometry as val UNION ALL SELECT 'POINT(1<BR>
>> 1)'::geometry as val) a,<BR>
>> (SELECT 'POINT(3 4)'::geometry as val UNION ALL SELECT 'POINT(1<BR>
>> 1)'::geometry as val) b;<BR>
>><BR>
>><BR>
>> ATB,<BR>
>><BR>
>> Mark.<BR>
>><BR>
>> --<BR>
>> Mark Cave-Ayland<BR>
>> Sirius Corporation - The Open Source Experts<BR>
>> <A HREF="http://www.siriusit.co.uk">http://www.siriusit.co.uk</A><BR>
>> T: +44 870 608 0063<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>
> _______________________________________________<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>
</FONT>
</P>
</BODY>
</HTML>