[fdo-users] RE: Property2ColNameChar

Traian Stanev traian.stanev at autodesk.com
Wed Jun 11 11:52:46 EDT 2008


True, but this only applies to some providers. Other providers, which can deterministically map property name to index, are penalized unnecessarily.

Traian


> -----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 11:51 AM
> To: FDO Users Mail List
> Subject: RE: [fdo-users] RE: Property2ColNameChar
>
> > we are missing "stanadard" index access to properties and than
> application can decide which one to use.
>
> Even so, the provider has to keep an internal mapping because the index
> of the property doesn't necessary match the index of the corresponding
> column (e.g. RevisionNumber column).
>
> Besides, doing everything under the hood has another advantage: it
> saves the conversion from wchar to char (usually needed when going from
> logical to physical) by caching the char value as well.
>
> Dan.
>
> -----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 11:15 AM
> 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
> _______________________________________________
> fdo-users mailing list
> fdo-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-users


More information about the fdo-users mailing list