[pgpointcloud] uncompressed pointcloud size

[Paul Ramsey]

Not a bug.
The pcpatch type is declared with storage ‘external’, so pgsql doesn’t attempt to compress it at all.
65535 * 8 * 8 = 4194487, raw, uncompressed data.
The geometry type is declared with storage ‘main’, which does allow pgsql to compress, if the size exceeds a page. So you’re seeing the post-zlib size when you run pg_column_size.
Basically one should never store uncompressed patches, just work with them in memory as necessary, IMO
P. 


--  
http://postgis.net  
http://cleverelephant.ca


On February 2, 2015 at 6:18:54 AM, Sandro Santilli (strk at keybit.net) wrote:
> Hello all,
> I've been playing with pgcloud today and was surprised by the size
> of uncompressed patches enough to write an email here.
>  
> I've inspected size using the PostgreSQL pg_column_size function.
>  
> The patch contains 65,535 points of 8 dimensions (of 8 bytes) each.
> With the "dimensional" compression, size is 40,441 bytes.
> Uncompressed, size is 4,194,487 bytes
>  
> The closest equivalent PostGIS multipoint (with half the dimensions)
> is is 68,595 bytes. Makes me think that if you could store double as
> many points in a MULTIPOINT you'd get double that size, which is
> 137,190 bytes (in reality you'd get a little less as SRID would not
> be repeated). In any case that's far away from the 4M reported for
> the uncompressed patch.
>  
> Could there be a bug in the code, fluffing the value far higher than
> really needed to store all values ? Or how can an uncompressed pcpatch
> be much bigger an a multipoint geometry (also uncompressed) ?
>  
> --strk;
>  
> () Free GIS & Flash consultant/developer
> /\ http://strk.keybit.net/services.html
>