[fdo-users] RE: Property2ColNameChar

Wed Jun 11 12:18:35 EDT 2008

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

OK suppose you do a "select *".

Then you get a feature reader back and you need to read property values, for example for geometry. You call

   Blah = reader->GetGeometry(L"GEOM");

Internally the provider has to map the L"GEOM" to a column index. This happens every time you need to access the value of any column via the FDO feature reader.

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 12: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