[pgpointcloud] uncompressed pointcloud size
Paul Ramsey
pramsey at cleverelephant.ca
Mon Feb 2 06:26:14 PST 2015
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
>
More information about the pgpointcloud
mailing list