[postgis-devel] Gserialized Enabled vs Disabled
Paragon Corporation
lr at pcorp.us
Thu Dec 30 22:25:48 PST 2010
I'll try to come up with an example that would force it to process. As far
as ST_Disjoint all the short-circuiting most be in the code. Its not using
any operators like ST_Intersects.
It just has this for definition
'$libdir/postgis-2.0', 'disjoint'
I thought the difference between the two was with the operators and index so
wasn't clear how it would affect this particular.
Yah the empties seem pretty harmless so its just these ones that aren't
empty that concern me. I'm just wondering if that is affecting your
performance the fact that gserialized is not exiting the party as quickly as
I would expect it to and hanging around for more drinks :)
-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Friday, December 31, 2010 1:19 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Gserialized Enabled vs Disabled
Can you force the old one to fail by avoiding the short circuits?
My guess was that most of the empty failures are happening because before
empty was a geometrycollection, which meant it got kicked out of a lot of
functions early on the basis of not being a handled type.
The new types is more of a mystery, but rather than puzzling over the
differences, is there a correct behavior we want to enforce consistently?
P
On Thu, Dec 30, 2010 at 10:06 PM, Paragon Corporation <lr at pcorp.us> wrote:
> I'm seeing a bunch of differences when doing a regress compare between
> these two
>
> Mostly with the way they handle empty geometries and the newer types
> like TIN.
>
> It's almost as if the serialized is not doing any short-circuiting and
> the non-serialized is.
>
> For example:
>
> 1) SELECT ST_Disjoint(ST_GeomFromEWKT('SRID=4326;POINT(-11.1111111
> 40)'),
> ST_GeomFromEWKT('SRID=4326;TRIANGLE((-71.0821 42.3036,-71.0821
> 42.3936,-71.0901 42.3036,-71.0821 42.3036))'))
>
>
> In the regular case - non-gserialized:
> This returns: t
>
> In the gserialized -- this returns
>
> Unknown geometry type: 14 - Triangle
>
> So it's like the non-gserialized is smart enough to realize that if
> the bounding box does not intersect there is no need to jump into geos
> or do anything further analysis - it knows they are disjoint.
>
> I'm seeing a lot of these silly failures. Which are perhaps by design.
>
> Thanks,
> Regina
>
>
> _______________________________________________
> 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
More information about the postgis-devel
mailing list