| From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
|---|---|
| To: | Ivan Trofimov <i(dot)trofimow(at)yandex(dot)ru> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: libpq: PQfnumber overload for not null-terminated strings |
| Date: | 2024-02-27 12:44:14 |
| Message-ID: | CAGECzQQ_cEU+8VtHOMe=fCPaS6q5YW+8-ThmAFf3hpTH5s_+wQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 27 Feb 2024 at 00:31, Ivan Trofimov <i(dot)trofimow(at)yandex(dot)ru> 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 that
PQfnumber shows up so big in your profile. I think it would probably
make sense to introduce a PQfnumber variant that does not do the
downcasing/quote handling (called e.g. PQfnumberRaw).
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2024-02-27 12:52:02 | Re: [PATCH] updates to docs about HOT updates for BRIN |
| Previous Message | Amit Kapila | 2024-02-27 12:35:14 | Re: Synchronizing slots from primary to standby |