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.
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? |