Re: libpq pipelineing

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

In response to

Responses

Browse pgsql-general by date

  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