Re: Protocol 3, Execute, maxrows to return, impact?

From: "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Protocol 3, Execute, maxrows to return, impact?
Date: 2008-07-10 05:54:17
Message-ID: 64b4daae0807092254m38f76553s62c7bf235a49f8a8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 10, 2008 at 05:31, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Stephen R. van den Berg" <srb(at)cuci(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-07-10 07:06:12 Re: Sorting writes during checkpoint
Previous Message Tom Lane 2008-07-10 03:31:10 Re: Protocol 3, Execute, maxrows to return, impact?