[fdo-users] RE: Property2ColNameChar

[Haris Kurtagic]

Sorry, I made mistake. I wanted to post this on internal list.

Haris

-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org
[mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Wednesday, June 11, 2008 5:15 PM
To: FDO Users Mail List
Subject: [fdo-users] RE: Property2ColNameChar

I have looked at the code of Property2ColNameChar and few questions pop
up.

I believe when I was developing King.Oracle I was posting that we would
need to have index access to properties, simillar as database client
APIs have. I am not sure but I would be suprised if other database
access software have implemented such mechanisems on data access level. 

To me , It looks like that we are missing "stanadard" index access to
properties and than application can decide which one to use.

Haris

-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org
[mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Wednesday, June 11, 2008 4:23 PM
To: FDO Users Mail List
Subject: RE: [fdo-users] PostGIS FDO Provider performance issues

My bet is that "something else" is the look up for the property in the
logical/physical collections of properties.
E.g. for 20 properties in the class the provider will do aprox.
2,000,000 wide string comparisons for 200,000 rows.
Actually it is 4 million because of IsNull() calls. This is the
performance killer.

The problem has been solved for rdbms providers by caching the
properties in the order they are fetched (at the first fetch). So the
property will be found either in the same position (after a IsNull) or
in the next slot. This is equivalent to fetching a property by index
rather by name.

The implementation is in GenericRdbms:
FdoRdbmsFeatureReader::Property2ColNameChar()

Hope this helps,
Dan.

-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org
[mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
Sent: Wednesday, June 11, 2008 3:03 AM
To: FDO Users Mail List
Subject: Re: [fdo-users] PostGIS FDO Provider performance issues

I would agree it's too much overhead, as this happening with Oracle as
well ( anyone else seen
this happen with another db?) perhaps there is something else in play.

How many rows are fetched by the client? Fetching one row at a time is
slower than returning blocks of 100 rows..

Using mapguide, it's always the mapguide process (ie FDO) and not the
database which is showing the high cpu

z



On Wed, Jun 11, 2008 at 4:56 PM, Carl Jokl <carl.jokl at keynetix.com>
wrote:
>
> It is true that there is extra overhead in performing the conversion
or going
> through FDO but I think it is fair to say that having PostGIS 16 to 20
times
> slower on the same data is more of a performance hit than would have
been
> expected.
> --
> View this message in context:
http://www.nabble.com/PostGIS-FDO-Provider-performance-issues-tp17756475
p17771210.html
> Sent from the FDO Users mailing list archive at Nabble.com.
>
> _______________________________________________
> fdo-users mailing list
> fdo-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-users
>



--
Zac Spitzer -
http://zacster.blogspot.com (My Blog)
+61 405 847 168
_______________________________________________
fdo-users mailing list
fdo-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
fdo-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
fdo-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-users