From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Samuel Williams <space(dot)ship(dot)traveller(at)gmail(dot)com> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: libpq pipelineing |
Date: | 2020-06-29 14:06:00 |
Message-ID: | 322743.1593439560@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Samuel Williams <space(dot)ship(dot)traveller(at)gmail(dot)com> writes:
> Those methods don't seem to have an equivalent in libpq - you can use
> PQgetResult but it buffers all the rows. Using single row mode results
> in many results for each query (seems like a big overhead).
Have you got any actual evidence for that? Sure, the overhead is
more than zero, but does it mean anything in comparison to the other
costs of data transmission?
> Maybe the statement about efficiency is incorrect, but it would be
> nice if you could incrementally stream a single result set more
> easily.
More easily than what? If we did not construct a PGresult then we would
need some other abstraction for access to the returned row, dealing with
error cases, etc etc. That would mean a lot of very duplicative API code
in libpq, and a painful bunch of adjustments in client code.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2020-06-29 14:43:30 | Re: EXTERNAL: Re: Netapp SnapCenter |
Previous Message | Paul Förster | 2020-06-29 13:59:38 | Re: EXTERNAL: Re: Netapp SnapCenter |