[postgis-devel] Bit setting to compress PostGIS geometries

[Daniel Baston]

Yes, this would tie in nicely with a precision model implementation.
So one question is whether to merge this in now as a utility function (after
tidying/documentation), or to wait and do it coherently as part of a
precision implementation.

I think it makes sense to store precision at the geometry level. By
default, any geometry would use full double precision unless it's
explicitly lowered with a function call. So most users would never notice.
Any overlay operation could then produce a result at the lowest precision
of its inputs, and we wouldn't have to clutter the function signatures with
an op_precision parameter like I did in my 2016? implementation.

We have one extra bit in the SRID, no? (There are 21 bits set aside for
SRID, but 2^20 > SRID_MAXIMUM). So we could combine this extra bit with the
3 spare bits after the SRID and represent all meaningful values of
precision (1-15).
Or we could store precision only in the 3 bits after the SRID, and not
allow all values of precision (there's little value in 1, 2, 3, 4, 12, 13,
and 14 in my opinion). We could also steal a bit from the flags ("readonly"
does not appear to be used).

This all assumes that we want an implementation of precision based around
significant digits. That's convenient for this use case, but I'd guess many
users expect precision in the sense of grid spacing, as is used (I think)
with the topology functions.

Dan

On Fri, Feb 16, 2018 at 9:46 AM, Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

> That's quite diabolical, and a nice freebie... and it brings us right
> back to discussions of precision models.
> Are they global, by table, by function call?
> Smaller objects will make for faster access, so it's a win, I think we
> should bring it in.
> Incidentally, I've been doing some point-in-polygon benchmarking, and
> the amount of time we spend just decompressing a toasted tuple in a
> p-i-p calculation with a large polygon can be 95% of the CPU. Over and
> over and over. Decompress it, check to see if it matches what's
> cached, repeat.
> For that use case, using "external" storage with a uncompressed header
> and compressed payload would be a big win. Small is good.
> P
>
>
>
> On Fri, Feb 16, 2018 at 6:38 AM, Daniel Baston <dbaston at gmail.com> wrote:
> > Hi,
> >
> > I've been experimenting with a cool technique to reduce the size of
> PostGIS
> > geometries by setting insignificant bits to zero, which makes the
> geometry
> > objects more compressible.
> >
> > I described the technique in a post here, which shows some test results:
> > http://www.danbaston.com/posts/2018/02/15/optimizing-postgis
> -geometries.html
> >
> > I'm on the fence about whether something like this has a place in the
> > PostGIS core, but am leaning towards "yes." What do others think?
> >
> > Dan
> >
> >
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180219/2614f291/attachment.html>