I certainly read Orest email as I answeard to it. In my email I was talking about slow performance of generic rdbms when I last time work with it while Orest was talking about performance in light of comparing it to current PostGIS provider.<div>
Haris.<div><br><br><div class="gmail_quote">On Mon, Nov 30, 2009 at 4:43 PM, Badreddine Karoui <span dir="ltr"><<a href="mailto:badreddine.karoui@autodesk.com">badreddine.karoui@autodesk.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">The performance was one of the criterias used to decide which
provider to use. See Orest’s email below.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Badreddine</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt">
<a href="mailto:fdo-internals-bounces@lists.osgeo.org" target="_blank">fdo-internals-bounces@lists.osgeo.org</a>
[mailto:<a href="mailto:fdo-internals-bounces@lists.osgeo.org" target="_blank">fdo-internals-bounces@lists.osgeo.org</a>] <b>On Behalf Of </b>Haris
Kurtagic<br>
<b>Sent:</b> Monday, November 30, 2009 10:26 AM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> Re: [fdo-internals] FDO PostGIS provider developments</span></p>
</div><div><div></div><div class="h5">
<p class="MsoNormal"> </p>
<p class="MsoNormal">I wouldn't like to go to much into discussion about generic
rdbms stuff. I think that priority should be having good PostGIS provider which
we can get with current resources.</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Just in short, when I started looking how to make provider
for Oracle, Generic RDBMS was first place to start looking. For me Generic
RDBMS was to complex , hard to work with and extend . Performance was
also bad.</p>
</div>
<div>
<p class="MsoNormal">That was few years ago, I would assume that it has improved
since but still I am afraid that Autodesk would be only maintaner of that
code. That would be main reason why I would like to have current PostGIS
available, which has not only Autodesk developers which could work on it.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Haris</p>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal">On Mon, Nov 30, 2009 at 2:36 PM, Zac Spitzer <<a href="mailto:zac.spitzer@gmail.com" target="_blank">zac.spitzer@gmail.com</a>> wrote:</p>
<p class="MsoNormal">2009/12/1 Haris Kurtagic <<a href="mailto:haris@sl-king.com" target="_blank">haris@sl-king.com</a>>:</p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">> Is
it necessary to replace current version, can't that be another
version of<br>
> provider ?<br>
> I was never able to get comfortable with generic rdbms stuff. In my
opinion<br>
> there are minuses too.</p>
</div>
<p class="MsoNormal">like?</p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
> I would like to have option of current code base to be continued if there<br>
> would be option at least for some time.<br>
> Haris<br>
><br>
> On Mon, Nov 30, 2009 at 2:14 AM, Orest Halustchak<br>
> <<a href="mailto:orest.halustchak@autodesk.com" target="_blank">orest.halustchak@autodesk.com</a>>
wrote:<br>
>><br>
>> Hi,<br>
>><br>
>><br>
>><br>
>> Autodesk has had interest from Map3D customers who want to use the FDO<br>
>> PostGIS provider to access and edit data using Map3D and other
products.<br>
>><br>
>><br>
>><br>
>> These customers have not been able to use this provider reliably with<br>
>> Map3D. We had a close look at the provider code to determine what work
would<br>
>> be needed to complete the implementation of schema and edit support
and fix<br>
>> other issues. Unfortunately, we found that the provider as it stands
today<br>
>> requires a lot of work to complete the implementation of required FDO<br>
>> interfaces and to add good unit test coverage. Things that still need
a fair<br>
>> bit of work include:<br>
>><br>
>> · Creating new schema
and new datastore<br>
>><br>
>> · Spatial filter
handling<br>
>><br>
>> · Huge memory leaks on
insert.<br>
>><br>
>> · Not all schema
commands are implemented.<br>
>><br>
>> · Enable and fix
transaction support.<br>
>><br>
>> · Constraint and
default values support.<br>
>><br>
>> · Lots of TODOs spread
all over the code<br>
>><br>
>> · Virtually no unit
tests exist.<br>
>><br>
>><br>
>><br>
>> We looked at the level of effort needed to complete that work. It was<br>
>> quite high. So, we looked at an alternative. There exists an earlier
open<br>
>> source community code base for a PostGIS provider that was started a
couple<br>
>> of years ago but not finished. That code base used the generic rdbms<br>
>> framework that is shared with the SQL Server Spatial, MySQL, and ODBC<br>
>> providers. Most of the schema processing is handled with that shared
code.<br>
>> We spent some time working with the current provider and the other
code base<br>
>> to determine the most efficient way to get to a completed provider
that<br>
>> would be robust, perform well, and be maintainable.<br>
>><br>
>><br>
>><br>
>> In the end, we determined that taking the earlier code base, adding<br>
>> support for the recent fdo interface changes, and completing other
parts<br>
>> that weren’t finished would take much less time. Also, based on
performance<br>
>> comparisons, we would get something that was much faster on inserts
and<br>
>> selects, e.g. the select performance is about six times faster and
schema<br>
>> describe is about three times faster. We couldn’t compare insert times
very<br>
>> well because the current provider kept crashing after a certain point
and we<br>
>> couldn’t insert a large number of features.<br>
>><br>
>><br>
>><br>
>> So, what we would like to do is complete our work to get a working
PostGIS<br>
>> provider and then replace the current open source code with our new
copy.<br>
>> Note that we plan to use native PostGIS schema without adding
additional<br>
>> metadata tables just as the current provider does. It will be able to
read<br>
>> any schemas created by the current version of the provider and itself
will<br>
>> generate generic PostGIS schemas.<br>
>><br>
>><br>
>><br>
>> We’ll need to submit an RFC for this, but we wanted to get this<br>
>> information out to you ahead of time.<br>
>><br>
>><br>
>><br>
>> At the same time, we are planning to change the connection parameters
to<br>
>> separate out the database name from the service name. This will make
it<br>
>> easier for users. They can identify the service (e.g. localhost:5432),
and<br>
>> then see the available datastores from which they can choose in a UI.
Then,<br>
>> PostGIS schema simply will map to FDO schema. The main drawback to
this is<br>
>> that any users with existing MapGuide feature sources and layer
definitions<br>
>> will have to update them.<br>
>><br>
>><br>
>><br>
>> In the end, we will end up with a good functioning provider that
performs<br>
>> well.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Regards,<br>
>><br>
>> Orest.<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> fdo-internals mailing list<br>
>> <a href="mailto:fdo-internals@lists.osgeo.org" target="_blank">fdo-internals@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> fdo-internals mailing list<br>
> <a href="mailto:fdo-internals@lists.osgeo.org" target="_blank">fdo-internals@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
><br>
><br>
<br>
<br>
</p>
</div>
</div>
<p class="MsoNormal"><span style="color:#888888">--<br>
Zac Spitzer<br>
Solution Architect / Director<br>
Ennoble Consultancy Australia<br>
<a href="http://www.ennoble.com.au" target="_blank">http://www.ennoble.com.au</a><br>
<a href="http://zacster.blogspot.com" target="_blank">http://zacster.blogspot.com</a><br>
+61 405 847 168</span></p>
<div>
<div>
<p class="MsoNormal">_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org" target="_blank">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a></p>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div></div></div>
</div>
<br>_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
<br></blockquote></div><br></div></div>