
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 22, 2019, at 9:08 AM, Bruce Rindahl <<a href="mailto:bruce.rindahl@gmail.com" class="">bruce.rindahl@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class="">Do you need proj-6 for this or just postgresql-12-dev?</div></div></blockquote><div><br class=""></div><div>Neither, it’s orthogonal to both those.</div><div><br class=""></div><div>P</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><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" class="">pramsey@cleverelephant.ca</a>> wrote:<br class=""></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 class="">

scaffolding on which new features using new flagging can be built.<br class="">

<br class="">

<a href="https://github.com/postgis/postgis/pull/421" rel="noreferrer noreferrer" target="_blank" class="">https://github.com/postgis/postgis/pull/421</a><br class="">

<br class="">

In order to get there, you'll note some structural changes around the code base<br class="">

<br class="">

- All access to gserialized internals is now behind an API that lives<br class="">

in gserialized.c<br class="">

- The homology between gserialized->flags and lwgeom->flags is now<br class="">

broken -- gserialized2 has an 8-bit gflags member, and an optional<br class="">

64-bit xflags area managed behind the api, while lwgeom->flags has<br class="">

been expanded to 16 bits for now, with room potentially to get to 24<br class="">

with some extra contortions as necessary in the future<br class="">

- That means you can continue to call FLAGS_SET/GET macros on<br class="">

lwgeom->flags, but you should no longer assume you can do so on<br class="">

gserialized->gflags, you should instead call the relevant<br class="">

gserialized_get_*() functions from the API<br class="">

- (All the above changes have been cleaned out of the code base, so<br class="">

this in on a going forward basis, there is no work to be done by<br class="">

anyone to implement the above, it's already done)<br class="">

- lwgeom_from_gserialized() will magically work regardless of whether<br class="">

it's fed a v1 or v2 serialization, so this code all works fine when<br class="">

slapped on top of a database full of old geometries<br class="">

- gserialized_from_lwgeom() (and the two functions riding on top of<br class="">

it, geometry_serialize() and geography_serialize(), which are<br class="">

preferred when calling from inside ./postgis) will write out v2<br class="">

geometries, so databases will slowly get re-written with the new form<br class="">

over time<br class="">

<br class="">

So far all this deck chair rearranging has resulted in no net-new<br class="">

functionality. I'm looking at two potential areas where the new<br class="">

serialization could be put to use before postgis3:<br class="">

<br class="">

- The extra flag space on gflags that has been freed up by moving the<br class="">

IsSolid flag into the xflags area could be used of an IsPoint flag, to<br class="">

allow a lightweight point type. A lightweight x/y point could then be<br class="">

24 bytes (varsize + srid/flags + x + y) instead of 32 bytes (varsize +<br class="">

srid/flags + type + padding + x + y), for a 25% savings for simple<br class="">

points.<br class="">

- An extended flag and optional data area to hold a hash code could be<br class="">

used to accelerate the prepared geometry cache for those cases where<br class="">

the cached object is large, avoiding much of the current repetitive<br class="">

decompression overhead.<br class="">

- Some kind of validity caching could be put into place for larger<br class="">

objects using a ValidChecked/IsValid pair of flags in the extended<br class="">

area. open question for me would be -- when to set those flags, what<br class="">

triggers it? obviously ST_MakeValid() could set it, but what about<br class="">

automatically for any large polygons during serialization?<br class="">

<br class="">

I apologize in advance for the fundamental ugliness of the work, I'm<br class="">

not an artist, I'm a tradesman.<br class="">

<br class="">

ATB,<br class="">

P<br class="">

_______________________________________________<br class="">

postgis-devel mailing list<br class="">

<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" rel="noreferrer" class="">postgis-devel@lists.osgeo.org</a><br class="">

<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer noreferrer" target="_blank" class="">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div>

_______________________________________________<br class="">postgis-devel mailing list<br class=""><a href="mailto:postgis-devel@lists.osgeo.org" class="">postgis-devel@lists.osgeo.org</a><br class="">https://lists.osgeo.org/mailman/listinfo/postgis-devel</div></blockquote></div><br class=""></body></html>