Right. Was trying it out now, compiling some osm-dbs with primary key generated with this morton encoding from lat,lon and the performance is even worse. Debugging with the sqlite-tool shows, that the page counts for specific queries are almost double then before.
Seems like, from the sqlite-side the only options is to have page size as big as possible and line-data in the blob-field as much compressed as possible. ------ Originalnachricht ------ Von: "Simon Slavin" <slav...@bigfraud.org> An: "SQLite mailing list" <sqlite-users@mailinglists.sqlite.org> Gesendet: 31.08.2018 19:07:36 Betreff: Re: [sqlite] Strategies to reduce page-loads? >On 31 Aug 2018, at 2:46pm, J Decker <d3c...@gmail.com> wrote: > >>There was a voxel engine that was claiming they were going to move to >>a >>morton encoding; and I was working with a different engine, so I built >>a >>simulator to test averge lookup distances; it was far more efficient >>to >>keep sectors of voxels (32x32x32) in flat indexing, which made the >>maximum >>distance 1025 > >I can confirm that SatNav units do not keep their maps in Morton code >order. It's not a no-brainer go-to solution for mapping. However, the >analysis done to figure out a good storage order is rather complicated >and off-topic for this list. > >Simon. >_______________________________________________ >sqlite-users mailing list >sqlite-users@mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
