[gdal-dev] RE: Optimizing random access in SQL result set of OGR DB drivers

[Martin Chapman]

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?

Martin 

-----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
better
> 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
layers
> returned when issuing a SQL request on OGR drivers that rely on databases
: PG
> driver, MySQL driver, SQLite driver (... ?). For people wanting to take
part,
> you might be interested in the below email exchange first.
> 
> After examining Martin's patches and reading its explanations, I cann see
2
> possibilities if we want to implement such optimization :

Even,

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