[postgis-tickets] [PostGIS] #3080: PostgreSQL 9.5 regress failure on st_reclass: possible performance regression for all of PostGIS base
PostGIS
trac at osgeo.org
Sun Mar 22 20:18:56 PDT 2015
#3080: PostgreSQL 9.5 regress failure on st_reclass: possible performance
regression for all of PostGIS base
--------------------+-------------------------------------------------------
Reporter: robe | Owner: dustymugs
Type: defect | Status: new
Priority: low | Milestone: PostGIS 2.2.0
Component: raster | Version: trunk
Keywords: |
--------------------+-------------------------------------------------------
Changes (by robe):
* owner: pramsey => dustymugs
* priority: blocker => low
* component: postgis => raster
Comment:
Seems I over-reacted. It appears the change Tom made only changes
behavior of inline tables and this redundant call stuff has always been
the case for real tables.
For example doing this:
{{{
DROP TABLE IF EXISTS t2;
CREATE TABLE t2(rast raster);
INSERT INTO t2(rast)
SELECT ST_SetValue(
ST_SetValue(
ST_AddBand(
ST_MakeEmptyRaster(100, 100, 10,
10, 2, 2, 0, 0, 0),
1, '32BF', 1, 0
),
1, 1, 1, 3.14159
),
1, 10, 10, 2.71828
) As rast;
SELECT
ST_Value(t.rast, 1, 1, 1),
ST_Value(t.rast, 1, 10, 10),
ST_BandNoDataValue(rast, 1)
FROM (
SELECT ST_Reclass(
rast,
ROW(1,
'a-100]:50-1,(-100-1000]:150-50,(1000-10000]:254-150', '8BUI', 0)
) AS rast FROM t2
) AS t;
}}}
Forces a call of of ST_Reclass twice even in PostgreSQL 9.4. So only
performance degradation would be a constant wrapped in a subquery not
using a CTE
So we just need to change this test to have an OFFSET 0 and call it a day.
--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/3080#comment:7>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
More information about the postgis-tickets
mailing list