<div dir="ltr">Hi Peter,<br><br>><span style="font-size:12.8px">I have been tasked with creating a revisioning system for geometries </span><span style="font-size:12.8px">stored by PostGIS. </span><br>> Postgres's compression algorithm (PGLZ?) is not optimised for delta encoding or high compression ratios.<br>> So are there any options short of me implementing user-defined functions to wrap a compression library?<br>> .. <span style="font-size:12.8px">a field would hold all revisions in a JSON </span><span style="font-size:12.8px">data structure.</span><div><span style="font-size:12.8px"><br></span>My tips for evaluating the compression :<br>- the TWKB format [1]<br>- cstore_fdw  (compressing JSONB data)  [2]  ( now : only load or append supported )<br><br>[1] "TWKB (Tiny Well-Known Binary) format. TWKB is a compressed binary format with a focus on minimizing the size of the output."<br>(  PostGIS >= 2.2.0 )<br><a href="http://postgis.net/docs/manual-2.2/ST_GeomFromTWKB.html">http://postgis.net/docs/manual-2.2/ST_GeomFromTWKB.html</a><br><a href="http://postgis.net/docs/manual-2.2/ST_AsTWKB.html">http://postgis.net/docs/manual-2.2/ST_AsTWKB.html</a><br><br>"TWKB applies the following principles:<br>-Only store the absolute position once, and store all other positions as delta values relative to the preceding position.<br>-Only use as much address space as is necessary for any given value. Practically this means that "variable length integers" or "varints" are used throughout the specification for storing values in any situation where numbers greater than 128 might be encountered."<br><a href="https://github.com/TWKB/Specification/blob/master/twkb.md">https://github.com/TWKB/Specification/blob/master/twkb.md</a><br><br>[2] "Compressing PostgreSQL JSONB data 6x using cstore_fdw" <div><a href="https://www.citusdata.com/blog/14-marco/156-compressing-jsonb-using-cstore-fdw">https://www.citusdata.com/blog/14-marco/156-compressing-jsonb-using-cstore-fdw</a><br><a href="https://www.citusdata.com/citus-products/cstore-fdw/cstore-fdw-quick-start-guide">https://www.citusdata.com/citus-products/cstore-fdw/cstore-fdw-quick-start-guide</a><br><a href="https://github.com/citusdata/cstore_fdw">https://github.com/citusdata/cstore_fdw</a> <br></div><div><br></div><div><br></div><div>Regards,<br>  Imre<div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-13 15:47 GMT+01:00 Peter Devoy <span dir="ltr"><<a href="mailto:peter@3xe.co.uk" target="_blank">peter@3xe.co.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have been tasked with creating a revisioning system for geometries<br>
stored by PostGIS.  To avoid data duplication I thought about storing<br>
only diffs but because that introduces other complications I am<br>
thinking about just storing each revision in its entirety and having a<br>
compression mechanism minimize size on disk.<br>
<br>
However, it seems to me that, quite rightly, Postgres's compression<br>
algorithm (PGLZ?) is not optimised for delta encoding or high<br>
compression ratios.  So are there any options short of me implementing<br>
user-defined functions to wrap a compression library?<br>
<br>
For clarity, with this method I am thinking each geometry would have a<br>
corresponding row in which a field would hold all revisions in a JSON<br>
data structure.<br>
<br>
<br>
Peter<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org">postgis-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/postgis-users</a></blockquote></div><br></div>