[pgpointcloud] low compression with pure xyz data

[Paul Ramsey]

For continuous data dimensional compression is probably only going to do common bits removal, and might not even do that, you might just get zlib on your column, you’d have to check the debug and see what it chose.
If your patches are well correlated (data from similar locations in same patch) then common bits will have more room to take out redundant info.
Storage should be ‘external’ that is correct, and I’m surprised it got switched back to main? Once you have your own compression scheme (as we do) you don’t want main storage anymore.
If storage is ‘main’ then “uncompressed” patches of 1000 points will probably end up compressed by the postgresql backend, to fit them onto pages. PostgreSQL really wants to compress things for you, it’s hard to stop it, unless you’re set to external storage.

P 

On November 23, 2015 at 6:58:27 AM, Rémi Cura (remi.cura at gmail.com) wrote:

Hey,
I'm a bit suprised by the poor perf of the dimensionnal compression on my simple XYZ data.

XYZ are declared as int32_t, data is centered on (0,0,0),
ranging from -0.20 to 0.20 , precision 0.00001, 2 millions points.
Patches contains avg 1000 points, about 1.5k rows

It achieves a 2x compression ratio over binary ply, and roughly the same compression ratio as zipping the binary ply.

More suprisingly, uncompressed patches occupy only 14% more (setting the storage to external).

Any idea why  ?

(by the way, for the pcpatch type, the default value should be 'external' and not 'main' I guess).

running 1.0.1

Cheers,
Rémi C


_______________________________________________
pgpointcloud mailing list
pgpointcloud at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgpointcloud
-- 
Paul Ramsey
Sent with Airmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgpointcloud/attachments/20151123/5c21e2a1/attachment.html>