Re: [gnome-db] libgda cursor support

["Vivien Malerba" <vmalerba gmail com>]

On 9/27/07, Murray Cumming <murrayc murrayc com> wrote:
> On Thu, 2007-09-27 at 14:53 +0200, Vivien Malerba wrote:
> > > > > I guess this should be implemented with FETCH ABSOLUTE.
> > > > > http://www.postgresql.org/docs/8.2/static/sql-fetch.html
> > > > > Does that seem appropriate?
> > > >
> > > > This could be implemented like that in the GdaPostgresCursorRecordset, yes.
> > > >
> > > > Otherwise for a more general approach (that is in
> > > > gda_data_model_move_iter_at_row() which is called if no specific
> > > > implementation exists)  we just need to call
> > > > gda_data_model_iter_move_{prev,next} as many times as requested (and
> > > > in the case of the postgres cursor recordset there might even be no
> > > > performance penalty at all because it fetches chunks of rows ar once).
> > >
> > > But wouldn't that mean that we have to fetch the data for 1000 rows (100
> > > chunks of 10, for instance) if I just want the data for row 1 and row
> > > 1000?
> >
> > You're right, I had not thought abou that... Then the only way is to
> > use FETCH ABSOLUTE into the GdaPostgresCursorRecordset code.
>
> Here is a patch to add that. It also adds some comments. Please review,
> because I feel very unsure about how to set the various pg_inf, pg_pos,
> etc variables. It seems to work in my test case.
>
> However, this text from
> http://www.postgresql.org/docs/8.2/static/sql-fetch.html
> is not very encouraging:
> "ABSOLUTE fetches are not any faster than navigating to the desired row
> with a relative move: the underlying implementation must traverse all
> the intermediate rows anyway."

But it may avoid to actually transfer the data to the client process's
memory which still saves time.

>
> But maybe this at least lets libgda benefit from an improvement in
> PostgreSQL in future.

Right.

I'll check the patch ASAP. In the meanwhile if it works for you, you
can use it as it is.

Thanks,

Vivien