<div dir="auto">Do you need proj-6 for this or just postgresql-12-dev?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 21, 2019, 4:02 PM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So, the PR finally builds and regresses, and includes the initial<br>
scaffolding on which new features using new flagging can be built.<br>
<br>
<a href="https://github.com/postgis/postgis/pull/421" rel="noreferrer noreferrer" target="_blank">https://github.com/postgis/postgis/pull/421</a><br>
<br>
In order to get there, you'll note some structural changes around the code base<br>
<br>
- All access to gserialized internals is now behind an API that lives<br>
in gserialized.c<br>
- The homology between gserialized->flags and lwgeom->flags is now<br>
broken -- gserialized2 has an 8-bit gflags member, and an optional<br>
64-bit xflags area managed behind the api, while lwgeom->flags has<br>
been expanded to 16 bits for now, with room potentially to get to 24<br>
with some extra contortions as necessary in the future<br>
- That means you can continue to call FLAGS_SET/GET macros on<br>
lwgeom->flags, but you should no longer assume you can do so on<br>
gserialized->gflags, you should instead call the relevant<br>
gserialized_get_*() functions from the API<br>
- (All the above changes have been cleaned out of the code base, so<br>
this in on a going forward basis, there is no work to be done by<br>
anyone to implement the above, it's already done)<br>
- lwgeom_from_gserialized() will magically work regardless of whether<br>
it's fed a v1 or v2 serialization, so this code all works fine when<br>
slapped on top of a database full of old geometries<br>
- gserialized_from_lwgeom() (and the two functions riding on top of<br>
it, geometry_serialize() and geography_serialize(), which are<br>
preferred when calling from inside ./postgis) will write out v2<br>
geometries, so databases will slowly get re-written with the new form<br>
over time<br>
<br>
So far all this deck chair rearranging has resulted in no net-new<br>
functionality. I'm looking at two potential areas where the new<br>
serialization could be put to use before postgis3:<br>
<br>
- The extra flag space on gflags that has been freed up by moving the<br>
IsSolid flag into the xflags area could be used of an IsPoint flag, to<br>
allow a lightweight point type. A lightweight x/y point could then be<br>
24 bytes (varsize + srid/flags + x + y) instead of 32 bytes (varsize +<br>
srid/flags + type + padding + x + y), for a 25% savings for simple<br>
points.<br>
- An extended flag and optional data area to hold a hash code could be<br>
used to accelerate the prepared geometry cache for those cases where<br>
the cached object is large, avoiding much of the current repetitive<br>
decompression overhead.<br>
- Some kind of validity caching could be put into place for larger<br>
objects using a ValidChecked/IsValid pair of flags in the extended<br>
area. open question for me would be -- when to set those flags, what<br>
triggers it? obviously ST_MakeValid() could set it, but what about<br>
automatically for any large polygons during serialization?<br>
<br>
I apologize in advance for the fundamental ugliness of the work, I'm<br>
not an artist, I'm a tradesman.<br>
<br>
ATB,<br>
P<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" rel="noreferrer">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div>