| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Protocol 3, Execute, maxrows to return, impact? |
| Date: | 2008-07-10 03:31:10 |
| Message-ID: | 21589.1215660670@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"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.)
> - Is it simply slowing down the protocol because every 64 rows I
> introduce a round-trip delay for the next PortalSuspended/Execute combo?
Yup; there's no free lunch ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen R. van den Berg | 2008-07-10 05:54:17 | Re: Protocol 3, Execute, maxrows to return, impact? |
| Previous Message | Abhijit Menon-Sen | 2008-07-10 03:11:40 | Re: Extending grant insert on tables to sequences |