#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: | master |
| 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 by , 10 years ago
| Milestone: | → PostGIS 2.2.0 |
|---|
comment:2 by , 10 years ago
| Milestone: | PostGIS 2.2.0 → PostGIS 2.1.4 |
|---|
then again maybe 2.1.4 since its not an API change but just a performance enhancement
comment:3 by , 10 years ago
| Keywords: | history added |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
follow-up: 6 comment:4 by , 10 years ago
Why can't the shortcut take place in presence of NODATA values?
comment:5 by , 10 years ago
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 by , 10 years ago
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 by , 10 years ago
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 ?
we can do this in 2.2 right. Let's be ambitious