[postgis-devel] gzip support for ST_AsMVT

nyurik yuriastrakhan at gmail.com
Sun Nov 3 08:29:39 PST 2019

The amazing ST_AsMVT() has two common usage patterns:  copy resulting MVTs to
a tile cache (e.g. .mbtiles file or a materialized view), or serve MVT to
the users (direct SQL->browser approach).  Both patterns still require one
additional data processing step -- gziping.

Thus, rather than having a horizontally scalable db plus a simple IO-bound
SQL->Web or a SQL->store process, one has to add a relatively CPU-intensive
gzipping layer.  This is especially relevant if I try to create a PG table
with the pre-generated tiles - I must use an external data compression
process to retrieve a tile, gzip it, and store it back, instead of running a
single query for copying all tiles.  My cursory look at the tile sizes
indicate gzipping shrinks MVTs 50% to 300%.

Note that a similar CPU-intensive step - creating MD5 tile hashes for a more
efficient storage - can be easily done with PG's `md5()` function, whereas
`gzip()` doesn't appear to exist.

I would like to propose two possible solutions:
* Implement ST_AsMVT(..., compress) parameter - NULL=no compression,
0-9=compression level.
   PROs:  adds just the required functionality to where it is needed (YAGNI
principle), does not require ungzip yet (ST_AsMVT is a one way function
without the corresponding MVT->Table method)
   CONs: less generic (unusable for non-MVT usage)
* Implement gzip() or ST_gzip()
   PROs:  a more generic approach not tied to MVTs
   CONs:  logically implies the need of ungzip(), requires PG community to
agree this functionality is needed


Sent from: http://postgis.17.x6.nabble.com/PostGIS-Dev-f3570762.html

More information about the postgis-devel mailing list