<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="">I think the wiki page outlines some of the desired changes. To an extent they can be made “backwards compatible” for older installations, using the version flags in gserialized. Things like an uncompressed header area, some kind of double-optimized compression on coordinate lists, perhaps an expandable header ala twkb, and use of ‘external’ storage to avoid the application of pglz compression to the (already compressed) coordinate lists.<div class=""><br class=""></div><div class="">The goal being faster access to header information for large objects. There’s a lot of potential balancing to do w/ that kind of format, including things like leaving smaller objects uncompressed for direct double access, etc, etc. It’s unfortunately a fair amount of work with unknown benefits, though to the extent the pglz consistently shows up as a major call point when profiling spatial joins, potentially quite worth it.</div><div class=""><br class=""></div><div class="">P<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 9, 2018, at 1:45 PM, Darafei Komяpa Praliaskouski <<a href="mailto:me@komzpa.net" class="">me@komzpa.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">What changes in on disk format are needed? Can they be solved by making a new type of geometry that will hold new format internally, and keep readers/headers for current format? This way the migration can be seamless and delayed and done even in minor. <br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On пн, 9 ліп 2018, 23:05 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">Well, that’s a big change and I was hoping to hold 3 for a change in the disk format rather than burn it for administrivia… interested to hear what others have to say. +/- 0<br class="">
P<br class="">
<br class="">
> On Jul 9, 2018, at 1:03 PM, Regina Obe <<a href="mailto:lr@pcorp.us" target="_blank" class="">lr@pcorp.us</a>> wrote:<br class="">
> <br class="">
> We've been quietly toying with this idea, but would like to put in stone.<br class="">
> <br class="">
> Instead of having yet another minor of 2, let's go to 3.0.<br class="">
> <br class="">
> Hey we went from 1.5 to 2, seems appropriate to go from 2.5 to 3.<br class="">
> <br class="">
> All PostGIS developers and packagers I'd like your feedback too since it<br class="">
> will sway our decision.<br class="">
> <br class="">
> My main reason for wanting to jump to 3.0 is so we can standardize on<br class="">
> dropping the minor version in our lib file.<br class="">
> <br class="">
> So that means 3.0 would have a lib file<br class="">
> postgis-3.whatever_extension_os_prefers.<br class="">
> <br class="">
> <br class="">
> No postgis-3.0 etc. just postgis-3<br class="">
> <br class="">
> And thenceforth all PostGIS from 3.0 on will no longer have the .minor<br class="">
> version and we will promise as a project to ensure we will not remove C-API<br class="">
> functions referenced in prior 3.whatever SQL api and never do so during the<br class="">
> series of a major release.<br class="">
> Thus making pg_upgrade possible without having install an older version of<br class="">
> PostGIS or to do hacks symlink lib files from older versions to newer or<br class="">
> having people have to ask us - is it okay to symlink?<br class="">
> <br class="">
> +1 for 3.0 <br class="">
> <br class="">
> Here are some other things on table for 3.0<br class="">
> <br class="">
> <a href="https://trac.osgeo.org/postgis/wiki/PostGIS3" rel="noreferrer" target="_blank" class="">https://trac.osgeo.org/postgis/wiki/PostGIS3</a> (breakout of postgis raster I<br class="">
> am totally against :) )<br class="">
> <br class="">
> don't forget we've got a code sprint coming up this September to discuss<br class="">
> this and other topics. Signup so we know how many people to expect.<br class="">
> <br class="">
> <a href="https://trac.osgeo.org/postgis/wiki/PostGISCodeSprint2018" rel="noreferrer" target="_blank" class="">https://trac.osgeo.org/postgis/wiki/PostGISCodeSprint2018</a><br class="">
> <br class="">
> <br class="">
> If you are only going to join remotely, it's okay to put your name on their<br class="">
> but with note (Remote)<br class="">
> <br class="">
> Thanks,<br class="">
> Regina<br class="">
> <br class="">
> _______________________________________________<br class="">
> postgis-devel mailing list<br class="">
> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" class="">postgis-devel@lists.osgeo.org</a><br class="">
> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank" class="">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br class="">
<br class="">
_______________________________________________<br class="">
postgis-devel mailing list<br class="">
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" class="">postgis-devel@lists.osgeo.org</a><br class="">
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="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=""></div></body></html>