>> Right now as a library writer in a higher-level language I'm forced to
>> either
>> * Sacrifice performance to ensure 'column_name' is null-terminated
>> (that's what some bindings in Rust do)
>
> I'd go with that. You would have a very hard time convincing me that
> the per-query overhead
I see now that I failed to express myself clearly: it's not a per-query
overhead, but rather a per-result-field one.
Given a code like this (in pseudo-code)
result = ExecuteQuery(some_query)
for (row in result):
a = row["some_column_name"]
b = row["some_other_column_name"]
...
a field-name string should be null-terminated for every field accessed.
There absolutely are ways to write the same in a more performant way and
avoid repeatedly calling PQfnumber altogether, but that I as a library
writer can't control.
In my quickly-hacked-together test just null-terminating a user-provided
string takes ~14% of total CPU time (and PQfnumber itself takes ~30%,
but oh well), please see the code and flamegraph attached.
