[gdal-dev] RE: Optimizing random access in SQL result set of OGR DB
even.rouault at mines-paris.org
Wed Aug 26 18:32:59 EDT 2009
Selon Martin Chapman <chapmanm at pixia.com>:
> Even and Frank,
> 1. I would absolutely not change any existing functionality of how FID is
> handled or you will screw up everyone's code that depends on that and will
> cause a lot of people serious grief.
> 2. I cannot remember exactly but I think SetNextByIndex was intended to
> solve this problem because I originally asked Frank to add it so I would
> look there first as Frank says. Not sure why I couldn't use it in my case
> but I think there was a reason.
> 2. If SetNextByIndex doesn't work for this case and you want to add ordinal
> row support perhaps adding a new interface (or inherited class) would be the
> answer. That way you don't screw up existing drivers and changes can be
> implemented gradually driver by driver where it makes sense. Maybe the new
> interface would be called IRandomAccessCursor or something like that but to
> match the OGR interface naming convention.
> How does that sound?
Why would you need a new interface ? Calling SetNextByIndex(nIndex) followed by
GetNextFeature() is exacly what you want, unless I have missed something.
SetNextByIndex() would just need to be implemented on those layers and
GetNextFeature() adapted to take it into account
> -----Original Message-----
> From: Frank Warmerdam [mailto:warmerdam at pobox.com]
> Sent: Wednesday, August 26, 2009 4:02 PM
> To: Even Rouault
> Cc: Martin Chapman; Gdal-Dev
> Subject: Re: Optimizing random access in SQL result set of OGR DB drivers
> Even Rouault wrote:
> > Martin,
> > I take the liberty to CC the list, as it is an interesting issue and it's
> > to go public if we want to make progress on that.
> > In a few words, this is about how we could speed up GetFeature() on the
> > returned when issuing a SQL request on OGR drivers that rely on databases
> : PG
> > driver, MySQL driver, SQLite driver (... ?). For people wanting to take
> > you might be interested in the below email exchange first.
> > After examining Martin's patches and reading its explanations, I cann see
> > possibilities if we want to implement such optimization :
> I haven't seen Martin's patches, but the normal way to provide indexed
> access to resultsets is the OGRLayer::SetNextByIndex() method. You
> pass the index into the current result set and then GetNextFeature()
> should read the indicated feature.
> Currently only very few providers implement this in a customized way,
> but it seems it would be better to expand that rather than introduce
> a new mechanism.
> Does this make sense?
> PS. there are reasonably good reasons why we want the FID to be the
> primary key where practical. I would hate to break that.
> Best regards,
> I set the clouds in motion - turn up | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush | Geospatial Programmer for Rent
More information about the gdal-dev