<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Holger,<br>
<br>
As Fran has already pointed at, gvSIG 2.0 will provide a new
implementation for the data access layer (dal), which avoids the need
for random position access, so in the case of a database, data is only
loaded when requested.<br>
<br>
Hopefully, gvSIG 2.0 will have less memory problems depending on the
size of a database table, but we still have to perform more testing to
stress those cases.<br>
<br>
Regards,<br>
<pre class="moz-signature" cols="72">--
Cèsar Ordiñana Navarro
Arquitecto Software gvSIG
DiSiD Technologies SL <a class="moz-txt-link-freetext" href="http://www.disid.com">http://www.disid.com</a></pre>
<br>
<br>
<br>
Francisco José Peñarrubia escribió:
<blockquote cite="mid:4B8EA6B8.3000904@scolab.es" type="cite">
<pre wrap="">Hi Holger.
I think this behaviour is different in gvSIG 2.0. The reason is in 2.0
release, the random access is not needed like in 1.9 release.
So, you only have 2 options, wait for 2.0 release, or use a where clause
in the layer creation. I think you can define your "working area" from
the dialog of postgis layer loading (in 1.9).
Best regards.
Fran.
Holger Jaekel escribió:
</pre>
<blockquote type="cite">
<pre wrap="">Dear gvSIG developers,
when we add a layer from PostGIS to gvSIG 1.9, we can see that two ressource intensive operations are performed on the database:
1. A database cursor is created for this layer in PostGisDriver.setData(IConnection, DBLayerDefinition), which selects all objects from the table
2. A Hashtable is filled in PostGisDriver.doRelateID_FID(), which contains one entry for each object from our layer.
We have to work with layers that contain more than 10,000,000 polygons. In that case, the cursor allocates many ressources on the database side, so this solution does not scale very well for many users. In the second step, gvSIG tries to create a Hashtable with >10,000,000 entries, which will create an OutOfMemoryException. This will also happen if we use "maxScale" for this layer.
Any hints how gvSIG can handle large layers?
Thank you very much for your help,
Holger
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
Gvsig_internacional mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gvsig_internacional@listserv.gva.es">Gvsig_internacional@listserv.gva.es</a>
<a class="moz-txt-link-freetext" href="http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional">http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional</a>
</pre>
</blockquote>
<br>
</body>
</html>