Re: Why does the raster type not have send/receive defined?
Lukas Panhirsch via postgis-users <[email protected]> Tue, 8 Apr 2025 17:42:25 +0200
| Newsgroups | gmane.comp.gis.postgis |
|---|---|
| Message-ID | <[email protected]> |
From what I understand I'd be prevented from using the BINARY format though, as it relies on send/recv. The available alternative would be to use the TEXT format of the raster, which is effectively just the binary WKB encoded in ASCII HEX. And I'd assume that the bandwidth and computational overhead of said TEXT form is too high to be more efficient than simple INSERTs using the binary format+ST_RastFromWKB for a relatively low amount of rows, though I could be wrong. Sincerely, Lukas On 4/8/25 17:31, Paul Ramsey wrote: > Copy vs insert is legit going to be faster, but that’s not a binary > cursor thing, it’s batching up all the transactions and parsing nicely > into one big bundle as COPY does. You should still be able to do a bulk > copy without using send/recv. > > P > >> On Apr 8, 2025, at 8:30 AM, Lukas Panhirsch >> <[email protected]> wrote: >> >> That makes sense, thank you both. >> I believe I've seen some performance improvements with COPY instead of >> INSERT for large amounts of vector rows against a PostgreSQL server with >> relatively high storage latency, but on the other hand I'm inserting far >> fewer rows in the raster case, so I doubt I'd see the same improvement >> there. >> >> Sincerely, >> Lukas >> >> On 4/8/25 17:18, Paul Ramsey wrote: >> > Yes this. The utility of the send/recv function are in supporting a >> > client that is using a binary cursor. This doesn’t even happen much for >> > vector data anymore (there was a brief period when we all felt it was de >> > rigeur, and then it got benchmarked and it wasn’t that noticeable at all >> > as a performance tweak, so everyone stopped, because it added >> complexity). >> > >> > P >> > >> >> On Apr 8, 2025, at 8:15 AM, <[email protected]> <[email protected]> wrote: >> >> >> >> I think it’s because postgis raster is not an OGC standard or any kind >> >> of standard outside of PostGIS so there hasn’t been much need for it. >> >> For example if you wanted to backup your postgis raster table, you’d >> >> just use standard pg_dump / pg_restore tools. >> >> Most use cases beyond that are importing from a different raster >> >> format or exporting to a different raster format which functions >> >>https://postgis.net/docs/en/RT_ST_FromGDALRaster.html <https:// >> postgis.net/docs/en/RT_ST_FromGDALRaster.html><https:// >> >>postgis.net/docs/en/RT_ST_FromGDALRaster.html <http://postgis.net/ >> docs/en/RT_ST_FromGDALRaster.html>> >> >>andhttps://postgis.net/docs/en/RT_ST_AsGDALRaster.html <andhttps:// >> postgis.net/docs/en/RT_ST_AsGDALRaster.html><https:// >> >>postgis.net/docs/en/RT_ST_AsGDALRaster.html <http://postgis.net/docs/ >> en/RT_ST_AsGDALRaster.html>> >> >> as well as the raster2pgsql commandline tool. >> >> *From:*Lukas Panhirsch via postgis-users <[email protected] <mailto:[email protected]>> >> >> *Sent:*Tuesday, April 8, 2025 9:28 AM >> >> *To:*[email protected] <mailto:[email protected]> >> >> *Subject:*Why does the raster type not have send/receive defined? >> >> Hello, >> >> >> >> I haven't used this mailing list before and couldn't figure out how to >> >> search in the archives, so I apologize if this has been answered before. >> >> >> >> Is there any specific reason why the raster type does not have the >> >> send/receive functions in its SQL type definition? >> >> The geometry type has these defined as conversions to/from EWKB, which >> >> are equivalent to ST_AsEWKB/ST_GeomFromEWKB if I understand correctly. >> >> Equivalent (E?)WKB conversion functions exist for rasters in the form >> >> of (RT_)ST_AsBinary/ST_RastFromWKB, but have to be called explicitly. >> >> I would like to use PostgreSQL features like COPY ... WITH BINARY with >> >> rasters, but it seems this is preventing me from doing so. >> >> >> >> Sincerely, >> >> >> >> Lukas >> > >