[postgis-users] Substantial different index use between 9.5 and 9.6 using Postgis
lr at pcorp.us
Sat Dec 3 15:19:08 PST 2016
Tracked it down. It's caused by the cost changes we made in 2.3. So it affects 9.5 running 2.3 as well.
I've committed one part which would fix your particular problem.
The fix, change the cost on ST_SetSRID from 10 to 1 as follows and that should fix this particular issue. There are other functions commonly used this way that we have to patch.
CREATE OR REPLACE FUNCTION st_setsrid(
RETURNS geometry AS
LANGUAGE c IMMUTABLE STRICT PARALLEL SAFE
From: postgis-users [mailto:postgis-users-bounces at lists.osgeo.org] On Behalf Of Bill Measday
Sent: Saturday, December 03, 2016 3:41 PM
To: postgis-users at lists.osgeo.org
Subject: Re: [postgis-users] Substantial different index use between 9.5 and 9.6 using Postgis
Thanks Regina - nice to know it wasn't just my incompetence!.
Good luck tracking down the root cause.
On 4/12/2016 6:53 AM, Regina Obe wrote:
For reference I have ticketed this as:
---------- message ----------
Never mind. Thanks to Brian Hamlin's nudging on IRC that he sees the issue
too, I was able to replicate it.
I think the reason I missed it in my testing is that it doesn't happen with
the more common cases of:
FROM e1 , e2
WHERE ST_Intersects(e1.geom, e2.geom);
Or where you use constants in ST_MakePoint like your example
But only in case where you have:
FROM e1 , e2
WHERE ST_Intersects(e1.geom, ST_SetSRID(ST_MakePoint(e2.longitude,
So I'll go ahead and ticket it and try to track down the root cause. I
suspect it affects all our relation functions.
Thanks for bringing to our attention,
postgis-users mailing list
postgis-users at lists.osgeo.org <mailto:postgis-users at lists.osgeo.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the postgis-users