Re: C libpq frontend library fetchsize - Mailing list pgsql-hackers

From Tom Lane
Subject Re: C libpq frontend library fetchsize
Date
Msg-id 13404.1268931601@sss.pgh.pa.us
Whole thread Raw
In response to Re: C libpq frontend library fetchsize  (Yeb Havinga <yebhavinga@gmail.com>)
Responses Re: C libpq frontend library fetchsize
List pgsql-hackers
Yeb Havinga <yebhavinga@gmail.com> writes:
> What if the default operation of e.g. php using libpq would be as 
> follows: set some default fetchsize (e.g. 1000 rows), then just issue 
> getrow. In the php pg handling, a function like getnextrow would wait 
> for the first pgresult with 1000 rows. Then if the pgresult is depleted 
> or almost depleted, request the next pgresult automatically. I see a lot 
> of benefits like less memory requirements in libpq, less new users with 
> why is my query so slow before the first row, and almost no concerns.

You are blithely ignoring the reasons why libpq doesn't do this.  The
main one being that it's impossible to cope sanely with queries that
fail partway through execution.  The described implementation would not
cope tremendously well with nonsequential access to the resultset, either.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Yeb Havinga
Date:
Subject: Re: C libpq frontend library fetchsize
Next
From: Josh Berkus
Date:
Subject: Re: Getting to beta1