Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group