Re: Protocol 3, Execute, maxrows to return, impact? - Mailing list pgsql-hackers

From Stephen R. van den Berg
Subject Re: Protocol 3, Execute, maxrows to return, impact?
Date
Msg-id 64b4daae0807092254m38f76553s62c7bf235a49f8a8@mail.gmail.com
Whole thread Raw
In response to Re: Protocol 3, Execute, maxrows to return, impact?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Protocol 3, Execute, maxrows to return, impact?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jul 10, 2008 at 05:31, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Stephen R. van den Berg" <srb@cuci.nl> writes:
>> I was wondering, if there is any real advantage to actually specify say
>> 64 for the maxrows parameter to the Execute message in the PostgreSQL
>> network protocol?

> There's no benefit in it from the server's perspective, if that's what
> you meant.  The point of the parameter is to allow the client to avoid
> running out of memory to store all of a huge query result --- it can
> pull it in sections, instead.  (Think of it as a built-in cursor
> FETCH facility.)

Then, from a client perspective, there is no use at all, because the
client can actually pause reading the results at any time it wants,
when it wants to avoid storing all of the result rows.  The network
will perform the cursor/fetch facility for it.
-- 
Sincerely,Stephen R. van den Berg.


pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: CommitFest rules
Next
From: "Stuart Gundry"
Date:
Subject: Re: Security and Data Protection Issues