On 2023-Jun-28, Dominique Devienne wrote:
> And if there's a better proxy to programmatically know the network
> traffic exchanged on the connection's socket, that's cross-platform?
> Obviously
> libpq itself knows, but I don't see any way to access that info.
>
> Perhaps tracing might? But will
On Wed, Jun 28, 2023 at 1:22 PM Tom Lane wrote:
> I wrote:
> > That number is the total space actually requested from malloc() for
> > the PGresult object. But we request space in blocks (typically 2KB
> > each), so there's some overhead due to fields not exactly filling
> > a block, unused spac
I wrote:
> That number is the total space actually requested from malloc() for
> the PGresult object. But we request space in blocks (typically 2KB
> each), so there's some overhead due to fields not exactly filling
> a block, unused space in the last block, etc. If you're testing
> with very sma
Dominique Devienne writes:
> Obviously from these results, I now realize PQresultMemorySize() returns
> something larger than what went across the network. Can someone explain
> how so?
That number is the total space actually requested from malloc() for
the PGresult object. But we request space
Hi,
To measure throughput, I'm timing exec time spent in LibPQ,
against the size of the result-set in bytes, as reported
by PQresultMemorySize().
*EXEC: 7x ( 130,867 rows, 54,921,532 bytes) in 0.305s
(171.8 MB/s)*
*EXEC: 8x ( 180,079 rows, 95,876,047 bytes) in 0.49
