1) Do we must understand that data store in manifold storage for example filename.map ( with drawing that have the prefix native in video ) is more efficient (in rendering time) using manifold itself that use data store in external *.map file like postgresql Server ?
Yes. For rendering displays that must reckon many objects, with only 22 to 44 million of them Manifold .map is a faster data store than a PostgreSQL database server, all other things (running on the same machine, etc.) being equal. If you get up to really huge numbers of objects, then I'd expect PostgreSQL would at some point be faster. That's mainly a function of how Manifold is currently tuned in terms of optimizing data access. It's smarter today to tune for best performance in the one to tens of GB range, given that's what almost everybody is actually working with, instead of 100's of GB. As data sizes continue to increase, at some point Manifold will invest a couple of months into the Map 2.0 initiative. Between that and implementing distributed data store in Map 2.0 (which PostgreSQL can do today), it would be reasonable to expect that Manifold's speed advantage with native store would still be there, with quite likely a visible edge over PostgreSQL even with terabyte data. So data store inside manifold filename.map is more efficient than Qgis that don' t implement their own driver/file-system ( fileproject extension with File OS system ) OR manifold when they use both the same Microsoft PostgresQL Driver .
Yes. Manifold using .map is much faster than QGIS running any native store, or QGIS running PostgreSQL, or Manifold running PostgreSQL. 2) I think when software use ( have to use ..mandatory ) third component (dll : here postgresql driver ) , then there is no difference beetween software that use the same components when focus on rendering here ( explicit in the vidéo) .
No, that is incorrect for two reasons. First, there are efficient and inefficient ways of using the same PostgreSQL dll to query a PostgreSQL database. Second, if there are bottlenecks within the client application an inefficient client will not be able to use the data PostgreSQL provides, to do things like generating a display that will fit on screen from 44 million objects, as fast as an efficient client that has few or no bottlenecks. QGIS isn't a parallel application, so it has many bottlenecks that Manifold does not have, and it also may not have the repertoire of methods Manifold can bring to bear on the most efficient possible use of the PostgreSQL drivers. The combination of the two is probably why Manifold usually can pull and utilize data out of PostgreSQL about twice as fast (or even faster) than Q. You see less of that effect with small data, or when zoomed in so that only relatively few objects need to be pulled from PostgreSQL. Q also does some tricks that are cheating, for example, it caches pre-rendered displays so if you go back to that it shows them instantly. But that's cheating with a multiuser DBMS because Q doesn't know if data has changed as a result of some other user or other process changing what is in the database. It could be showing objects, many of them, that aren't there anymore. It's one of those classic "not quite right but looks OK" things that you see in Q. But even with all that, and even considering QGIS was originally created to display data from PostgreSQL, Manifold is still visibly faster at displaying data from PostgreSQL.
|