I never tried my SISDB PostGIS/Oracle plugin with 10 milions records, but it always worked flawlessy up to a few hundred thousands, so you may give it a try. Obviously, beeing it a DataStore, it will be read-only.
Regarding the max features option, I don't think it would be useful, because the first "n" records may well be all together inside a relatively small area, so you won't get an "overview" of your data. What's needed is a few metadata so that a data-access plugin could "tell" OpenJUMP how may records a certain table contains and OpenJUMP could decide if it would be able to display it or not. Then one should create inside it's database an "overview" table (or several of them), so that one or the other will be used accordingly to current zooming. Again a few metadata could be useful to describe this "group" of tables so that OpenJUMP could automatically choose the best one, but maybe this would be too much... Maybe a plugin could be developed for OpenJUMP that helps building such tables (raster too could prove useful for "overviews" instead vectors). Such a plugin could scan the entire record set returned by a data-access plugin and it will keep only a small amount of records such that they're well scattered across the space. The resulting layer could then be saved as an "overview" table. Anyway this entire work may also be done inside the database without needing any changes on OJ side. Just thinking out aloud here, but in this moment I can't actually work on any of it... :-( Bye Paolo Rizzi P.S: Actually I never tried my plugin with newer versions of OJ, so it may not work at all!!! > -----Messaggio originale----- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] conto di > Jukka Rahkonen > Inviato: domenica 6 aprile 2008 16.25 > A: jump-pilot-devel@lists.sourceforge.net > Oggetto: [JPP-Devel] PostGIS driver improvements > > > Hi, > > I made my first large PostGIS table with nearly ten million > rows. Untill this I > had thought that OpenJUMP works very well with PostGIS but > now I am not sure > anymore. What I say is about the native PostGIS driver, I > have not tried the > others with this large table. > > I believe that the first problem I notised actually makes all > big PostGIS tables > unusable slow and I am not sure if it really needs to be so. > OpenJUMP seems to start PostGIS query by sending: > SELECT AsBinary(find_extent( 'table', 'geom' )) > > I could not find function find_extent from PostGIS manual but > I suppose it is > doing the same as > SELECT extent(geom)from table; > This will mean full scan to geometry table every time than > PostGIS layer is > accessed. Index does not help with this function and it takes > several minutes to > run the query with my 10 million row table. The final query > returning the > geometries takes just seconds. I wonder why these exact > extents are queried? It > looks like coming from here (taken from CVN.txt): > 2006-05-08 16:20 jaquino > * > com/vividsolutions/jump/datastore/postgis/PostgisDSMetadata.java: > Use find_extent for PostGIS extents > > Alternative query > SELECT estimated_extent('table','geom'); > is returning the result immediately, but it is not accurate. > I do not know for > what OpenJUMP is using and needing the exact extents of the > database layer, or > if estimated extents could be used instead. > > Another problem is that with a big database table it is too > simple to send > queries which will leed to memory running out and a total > jam. All that is > needed is to zoom out too far. Perhaps situation could be > done more safe for the > user by adding an option to limit the number or returned > features? This option > should be selectable in the Add datastore layer and Run > datastore query dialogs, > I believe it would need just adding LIMIT max_number to > PostGIS queries. I > understand this would be dangerous as well if the user does > not realise that the > query did not give a full set of data. So I am not if this > is a good idea of > all. Perhaps there could be a warning message in case of > max_features=returned_features? > > Regards, > > -Jukka Rahkonen- > > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java .sun.com/javaone _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
