[fdo-users] RE: Property2ColNameChar

Wed Jun 11 12:54:43 EDT 2008

OK, I agree that is good to have. But unless the provider is enhancing fetching by name, it will end up having 2 ways to fetch: slow and fast.

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 12:30 PM
To: FDO Users Mail List
Subject: RE: [fdo-users] RE: Property2ColNameChar

Data is access by index by database client software.
Usually, when they allow by name they convert to get by index.

Accessing via column name means adding additional mapping.

Also in function Property2ColNameChar you mantioned property name is
converted to index.

So for FDO providers also, access by index is naturall way to go.

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 6:15 PM
To: FDO Users Mail List
Subject: RE: [fdo-users] RE: Property2ColNameChar

Yes, but it also true that the providers already enhanced will be
penalized without a real benefit because they have to implement "Get by
index" :-)

And how would it help in the most common use case, "Select *" ?

Dan.

-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org
[mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Wednesday, June 11, 2008 11:53 AM
To: FDO Users Mail List
Subject: RE: [fdo-users] RE: Property2ColNameChar

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
_______________________________________________
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