Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#2829 closed enhancement (fixed)

[raster] Short-cut ST_Clip when extent fully contains raster extent

Reported by: strk Owned by: Bborie Park
Priority: medium Milestone: PostGIS 2.1.4
Component: raster Version: trunk
Keywords: history Cc:

Description

When the extent passed to ST_Clip is bigger than the extent of the raster, the function could return earlier, skipping the deserialization completely.

Change History (7)

comment:1 Changed 5 years ago by robe

Milestone: PostGIS 2.2.0

we can do this in 2.2 right. Let's be ambitious :)

comment:2 Changed 5 years ago by robe

Milestone: PostGIS 2.2.0PostGIS 2.1.4

then again maybe 2.1.4 since its not an API change but just a performance enhancement

comment:3 Changed 4 years ago by Bborie Park

Keywords: history added
Resolution: fixed
Status: newclosed

Fixed in -trunk as of r12833. Fixed in -2.1 as of r12834

comment:4 Changed 4 years ago by strk

Why can't the shortcut take place in presence of NODATA values?

comment:5 Changed 4 years ago by strk

Also, if the wrapper can be done in SQL it would be inlined by PostgreSQL (possibly making use of indexes), while in plpgsql it won't be possible (and at that time could be done directly in C).

Am I right Robe ? Or did things change recently ?

comment:6 in reply to:  4 Changed 4 years ago by Bborie Park

Replying to strk:

Why can't the shortcut take place in presence of NODATA values?

If the user-specified NODATA differs from the band's NODATA, all pixels of the band has to be touched so as to change values to the new NODATA value from the old NODATA value.

comment:7 Changed 4 years ago by strk

Ah, thanks. I thought it was about NODATA values being present in the raster, rather than passed as parameter. I didn't even know there was a NODATA parameter (too many overloads :)

Forget the SQL implementation notes as there's no way an ST_Clip call would be using an index (unlikely to use WHERE ST_Clip...). Having it done within the C function though should still be faster though. Maybe for another ticket ?

Note: See TracTickets for help on using tickets.