On Tue, 27 Feb 2024 at 15:49, Ivan Trofimov wrote:
> Caching the result of PQfnumber could be done, but would result in
> somewhat of a mess on a call-site.
To be clear I meant your wrapper around libpq could internally cache
this, then the call sites of users of your wrapper would not need to
be
However, I do think you could convert this per-row overhead in your
case to per-query overhead by caching the result of PQfnumber for each
unique C++ string_view. Afaict that should solve your performance
problem.
Absolutely, you're right.
The problem here is not that it's impossible to write i
On Tue, 27 Feb 2024 at 00:31, Ivan Trofimov wrote:
> I see now that I failed to express myself clearly: it's not a per-query
> overhead, but rather a per-result-field one.
I'm fairly sympathetic to decreasing the overhead of any per-row
operation. And looking at the code, it doesn't surprise me t
Ivan Trofimov writes:
>> If you need counted strings
>> for PQfnumber, wouldn't you need them for every single other
>> string-based API in libpq as well?
> No, not really.
> Thing is, out of all the functions listed in "34.3.2. Retrieving Query
> Result Information" and "34.3.3. Retrieving Oth
Thanks for the quick reply.
If you need counted strings
for PQfnumber, wouldn't you need them for every single other
string-based API in libpq as well?
No, not really.
Thing is, out of all the functions listed in "34.3.2. Retrieving Query
Result Information" and "34.3.3. Retrieving Other Res
Ivan Trofimov writes:
> Would you be willing to review a patch that adds an `PQfnumber` overload
> that takes a `field_name` size as well?
I'm a little skeptical of this idea. If you need counted strings
for PQfnumber, wouldn't you need them for every single other
string-based API in libpq as w
